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ABSTRACT 

./ 

I 

Good  techniques  for  VLSI  design  change  management  do  not  now  exist.  A  principal  reason 
is  the  absence  of  effective  methods  for  the  specification  of  abstract  interfaces  for  VLSI  designs. 

This  dissertation  presents  a  new  approach  to  such  specification,  an  approach  that  extends  to  the 
VLSI  domain  D.L.  Parnas's  techniques  for  precise  specification  of  abstract  software  design  inter¬ 
faces  to  the  VLSI  domain.  The  proposed  approach  provides  important  new  features,  including 
scalability  to  VLSI  design  levels,  integration  into  the  design  life-cycle,  and  a  uniform  treatment  of 
functional,  electrical,  and  geometric  design  information.  A  technique  is  also  introduced  for 
attaching  a  value  to  the  degree  of  specification  adherence  of  a  candidate  module. 

1 

To  illustrate  and  evaluate  the  proposed  approach,  an  example  specification  method  using  it  j 

is  described  and  evaluated  experimentally.  I 
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CHAPTER  1 


INTRODUCTION 

1.1  Definition  of  the  Problem. 

VLSI  design  is  integrated  circuit  design  in  which  brute  force  no  longer  works.  The  major 
concern  in  VLSI  design  is  the  management  of  complexity  [Mudg8I,  S6qu83],  not  just  putting 
together  a  system  with  whatever  means  are  handy. 

Traditional  techniques  for  complexity  management,  such  as  hierarchy,  restriction,  and  struc¬ 
turing,  have  been  applied  in  the  VLSI  context:  nevertheless,  the  design  process  is  still  costly,  and 
hundreds  of  designer-years  are  being  invested  in  the  development  of  state-of-the-art  VLSI  circuits 
|Latt81,  Cane83).  The  unconstrained  nature  of  the  VLSI  design  medium  leads  to  some  of  this  co6t 
[S£qu83j,  in  that  only  inefficient  algorithms  are  available  to  apply  to  the  typically  NP-hard  prob¬ 
lems,  such  as  one-dimensional  placement  [Valt82]  and  optimal  routing  [John82],  encountered  in 
design  construction  and  verification.  Nevertheless,  while  such  traditional  costs  of  VLSI  design  are 
still  the  subject  of  much  research,  another  source  of  cost,  only  lately  recognized,  is  becoming  a 
major  concern  among  designers.  This  cost  arises  from  the  ripple  effect  of  changes  during  the 
design  process  [Wern83],  and  its  seriousness  stems  from  its  particular  sensitivity  to  the  increases 
in  complexity  that  characterize  modern  VLSI  design.  Belady  and  Lehman’s  work  |Bela79),  for 
example,  suggests  that  for  software  systems  “increasing  system  complexity  leads  to  a  regenerative, 
highly  non-linear,  increase  in  the  effort  and  cost  of  system  maintenance  and  also  limits  ultimate 
system  growth.”  While  similar  studies,  to  my  knowledge,  have  not  yet  been  directed  specifically 
at  VLSI  systems  evolution,  there  is  good  reason  to  suspect  that  the  effects  of  progressive  changes 
on  VLSI  systems  are  comparable. 

Furthermore,  this  "cost  of  change”  compounds  in  the  following  way.  Competitive  pressures 
for  denser,  more  capable,  and  hence  more  complex  circuits  beget  increased  refinement  of  designs, 
or  increased  change.  Such  increased  change,  Werner  notes,  is  necessitated  by  elevated  perfor¬ 
mance  standards  for  modern  chips,  possibly  even  requiring  retrofitting  a  design  in  progress  to 
include  new  technologies  or  capabilities.  However,  the  same  competitive  pressures  also  demand 
early  production  of  these  more-complex  chips,  so  that  larger  teams,  partitioning  the  design  task, 
are  assembled  to  meet  delivery  schedules  accelerated  by  intense  competition.  Increasing  complex¬ 
ity  thus  has  two  effects:  (1)  more  change;  and  (2)  larger  design  teams.  As  Brooks  {Broo75j  notes, 


either  effect  alone  increases  the  amount  of  communication  required  in  the  design  project,  and  the 
cost  of  this  communication  must  be  added  to  the  amount  of  design  work  to  be  done.  The  combi¬ 
nation  of  these  effects  compounds  costs  of  communication  and  thus  of  design,  making  the  cost  fac¬ 
tors  of  design  in  the  multi-designer  environment  significantly  different  from  those  that  have  been 
traditionally  applied. 

Consequently,  as  VLSI  circuits  grow  larger,  the  co6t  of  change  management,  especially  in 
the  now-typical  multi-person  design  effort,  may  well  become  the  primary  concern  in  the  VLSI 
design  process.  Because  current  VLSI  design  techniques  focus  primarily  on  developing  correct  ini¬ 
tial  designs  and  not  yet  on  the  management  of  design  change,  the  development  and  study  of  VLSI 
design  change  management  techniques  are  timely  and  important. 

1.2  Potential  Contribution  from  Software  Engineering  Techniques. 

There  have  been  numerous  recent  suggestions  (for  example,  see  [Rade82,  Kuni84,  Musa85]) 
that  transfer  of  design  technology  from  software  engineering,  which  has  dealt  with  systems  with 
similar  numbers  of  components  for  at  least  a  decade,  might  either  improve  the  theoretical  base  for 
VLSI  design  or  at  least  enhance  the  effectiveness  of  emerging  VLSI  design  methodologies.  Slauin 
|S#qu83]  supports  this  suggestion  by  listing  the  following  software  design  characteristics  that  pos¬ 
sess  counterparts  in  VLSI  design. 

a.  Appropriate  design  representations  are  crucial  to  design  success. 

b.  Abstraction  provides  an  appropriate  vehicle  for  dealing  with  complexity.  The  possibility  of 
exploiting  such  abstractions,  using  high-level  languages,  is  promising. 

c.  At  the  lowest  level,  on  the  other  hand,  the  design  may  be  restricted  to  a  limited  set  of  well- 

understood  constructs. 

d.  The  design  task  can  be  partitioned  and  structured.  For  example,  functional  design  can  be 
separated  from  implementation. 

e.  Testing  of  the  filial  realization  against  a  well-defined  system  specification  is  essential. 

f.  “Of  crucial  importance  in  the  construction  of  large  and  complex  systems  is  a  good  set  of  tools 
and  a  suitable  design  method.” 

In  contrast  to  VLSI  design,  software  engineering  has  seen  much  research  directed  toward  design 
methodologies,  and  the  application  of  principles  from  these  methodologies  to  VLSI  design  is  a 
promising  and  relatively  unexplored  idea.  Such  adaptation  of  software  engineering  methodologies 


to  VLSI  design  is  certainly  nontrivial,  because  the  latter  must  take  into  account  additional  con* 
cerns  such  as  geometric  and  electrical  limitations.  Nevertheless,  it  is  readily  conceivable  that 
transfer  of  concepts  from  software  engineering  could  contribute  to  the  development  of  an 
improved  theoretical  base  in  VLSI  design.  Such  improvement  would  aid  both  the  teaching  of 
VLSI  design  principles  and  the  construction  of  more  capable  automated  design  tools. 

Despite  the  quantity  of  methodological  research  in  software  engineering,  however,  most 
modern  software  design  methodologies  do  not  specifically  address  the  factor  of  change  in  the 
design  process.  In  this  regard,  the  software  design  techniques  of  D.L.  Parnas  are  conspicuously 
exceptional.  His  techniques,  specifically  those  of  information  hiding,  hierarchical  structuring  for 
design  families,  and  precise  specification,  have  demonstrated  the  potential  to  become  the  nucleus 
of  a  coherent  approach  to  the  software  change  management  problem.  The  overall  motivation  for 
my  current  research,  then,  has  been  to  investigate  how  these  techniques  can  be  applied  to  manage 
change  in  the  VLSI  design  proc*  v 

1.8  Determination  of  Research  Objectives. 

A  research  program  that  conscientiously  investigates  the  transferability  of  Parnas’s  tech¬ 
niques  to  VLSI  design  change  management  would  include: 

a.  An  extension  of  information  hiding,  hierarchical  structuring  for  families  of  designs,  and  pre- 

cise  specification  into  the  VLSI  domain  by: 

(1)  developing  a  realistic  model  of  the  contemporary  VLSI  design  process; 

(2)  identifying  in  the  model  the  points  at  which  decisions  crucial  to  the  techniques  are 

made; 

(3)  constructing  for  these  decision  points  a  set  of  criteria  that  guide  effective  design  change 

management. 

b.  The  development  of  an  integrated  set  of  VLSI  tools  that  enable  a  designer  to  use  the  cri¬ 

teria  developed  in  task  a  to  manage  design  change. 


c.  An  assessment  of  the  effectiveness  and  extensibility  of  the  design  change  management  pro¬ 
cedure  so  devised. 

The  scope  of  such  a  research  program  clearly  exceeds  that  of  a  single  dissertation.  Conse¬ 
quently,  it  has  been  necessary  to  identify  and  order  the  component  research  problems  embodied 
by  this  program. 

l.S.l  Component  Research  Problemt  and  Their  Interdependencies. 

1.9. 1.1  Specifying  Abstract  Interfacet  for  VLSI  Designs. 

Britton,  Parker,  and  Parnas  [Brit81a]  define  an  "interface”  between  two  programs  as  “the 
6et  of  assumptions  that  each  programmer  needs  to  make  about  the  other  program  in  order  to 
demonstrate  the  correctness  of  his  own  program.”  An  abstract  interface  specification,  in  their 
sense  of  the  term,  has  been  carefully  limited  in  content  to  a  description  of  only  these  assumptions, 
so  that  the  specification  describes  not  a  single  interface  but  a  class  of  interfaces.  More  than  one 
module  or  design  thus  fits  the  interface,  and  the  interface  is  robust  under  certain  types  of  changes. 

Abstract  interface  specification  of  VLSI  design  modules  is  a  largely  unstudied  problem.  This 
lack  of  attention  is  surprising  in  light  of  the  growing  realization  that  existing  VLSI  design 
specification  techniques  are  inadequate: 

there  are  no  real  tools  for  developing  and  simulating  high-level  specifications,  so  most  work  must 
be  done  by  hand.  There  are  also  problems  with  casting  the  specification  in  the  proper  form. ...The 
process  of  specification  is  intimately  involved  with  the  kinds  of  design  tools  available  f\VraJ184j. 

I  believe  that  the  primary  reason  for  this  inadequacy  is  that  most  references  to  “specification”  in 
\TSI  are  to  dear-box  specifications,  frequently  at  the  logic  level  Clear-box  specifications  address 
module  interfaces  only  indirectly,  by  prescribing  an  implementation  of  internal  module  logic  or 
circuitry.  Clear-box  specifications,  then,  blur  architectural  and  implementational  concerns; 
abstract  interface,  or  "black-box,”  specifications  keep  these  concerns  separate.  At  VLSI  complex¬ 
ity  levels,  separation  of  these  concerns  is  essential.  Clear-box  specification  techniques  do  not  scale 
up,  as  can  be  plainly  seen  from  the  difficulty  of  inferring  the  function  from  even  an  MSl-level  cir¬ 
cuit  diagram.  More  seriously,  however,  the  merging  of  architectural  and  implementation  issues  in 
large-scale  system  design  significantly  hinders  the  partitioning  of  the  design  task  and  degrades  (if 
not  destroys)  the  conceptual  unity,  hence  the  usefulness  and  robustness  to  change,  of  the  resulting 
system  [Blaa81].  The  development  of  effective  abstract  interface  specificatic  techniques  for  VLSI 
designs  is  thus  of  critical  importance. 


l.S.l.t  Quantifying  Ease  of  Change  of  VLSI  Detign*. 

One  criticism  justly  raised  about  methodological  research  is  that  claimed  benefits  for  pro* 
posed  methods  are  frequently  unsubstantiated.  To  avoid  this  criticism,  one  would  like  to  have  an 
impartial  means  of  quantifying  the  degree  to  which  a  given  VLSI  design  is  easy  or  difficult  to 
change;  then,  based  on  this  quantification,  the  merits  of  various  change  management  techniques 
could  be  compared. 

Preliminary  investigation  into  quantifying  ease  of  change  suggests  that,  first,  a  metric  is 
needed  for  change  itself,  so  that  the  “difference”  between  two  VLSI  designs  can  be  measured.  A 
modest  amount  of  experimentation  into  developing  a  change  metric  was  conducted  in  the  context 
of  this  exploration  }Gros84].  This  experimentation  investigated  measuring  VLSI  design  change  as 
a  difference  in  design  information  content,  going  on  to  attempt  to  measure  design  information  by 
counting  various  discrete  design  components  (analogous  to  software  science  approaches  such  as 
those  described  by  Halstead  [Hals77],  McCabe  [McCa76j,  or  Albrecht  and  Gaffney  [Albr83]). 
Techniques  employing  such  approaches  will  probably  need  to  be  complex  to  capture  design  infor¬ 
mation  content  successfully.  Further,  there  may  be  assumptions  embedded  in  the  design  that 
render  desirable  information  components  uncountable,  suggesting  that  such  metrics  must  be 
derived  from  a  design  representation  that  also  embodies  these  assumptions.  An  abstract  interface 
specification  for  the  design  is  such  a  representation. 

l.S.l.S  Using  Information  Hiding  in  VLSI  Design  Modularization. 

The  decomposition  of  a  VLSI  design  into  modules  is  an  important  phase  of  the  design  pro¬ 
cess.  In  a  study  oi  decomposition  criteria,  Heath  [Heat&3]  has  found  that  information  hiding 
[Parn72b,  Brit81a]  is  a  desirable  basis  for  VLSI  design  decomposition  whenever  robustness  under 
change  is  a  primary  design  objective.  At  the  same  time,  however,  he  notes  that  VLSI  design 
modularization,  using  any  criterion,  requires  the  external  aspects  of  each  module  to  be 
“sufficiently  and  precisely  specified.”  Because  information  hiding  and  modularization  are  so 
directly  interconnected,  precise  interface  specification  techniques  for  VLSI  designs  are  essential  if 
the  benefits  of  information  biding  are  to  be  obtained. 
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1.8. 1.4  Creating  Broad  Familiei  of  VLSI  Derignt. 

Parnas  (Parn76aj  characterizes  a  set  of  programs  as  a  family  “whenever  it  is  worthwhile  to 
study  programs  from  the  set  by  first  studying  the  common  properties  of  the  set  and  then  deter* 
mining  the  special  properties  of  the  individual  family  members.”  It  would  be  useful  to  learn 
whether  considering  the  successive  versions  of  an  evolving  VLSI  design  as  a  family  has  the  poten* 
tial  to  reduce  the  cost  of  VLSI  design  development  and  maintenance.  There  is  some  evidence  in 
the  affirmative  [Gros83b|. 

Nevertheless,  exploiting  the  family  concept  depends  critically  on  the  availability  of 
precisely-specified  intermediate  derignt  that  can  serve  as  checkpoints  for  design  backtracking.  To 
the  extent  that  these  intermediate  designs  can  be  characterized  by  their  interfaces,  progress  in 
research  seems  to  hinge  once  again  on  the  availability  of  techniques  for  VLSI  design  interface 
specification. 

1.8. 1.5  Determining  Extent  of  Required  Revalidation  Following  VLSI  Detign  Change. 

The  decision  to  change  a  VLSI  design  brings  about  the  following  activities. 

a.  Determine  the  nature  and  scope  of  the  change  required. 

b.  Perform  the  change. 

c.  Ensure  the  correctness  of  the  design  by  testing  following  the  change. 

Full  testing  of  the  design  following  each  change,  however,  is  ccetly  and  often  unnecessary.  Unfor¬ 
tunately,  there  currently  exist  no  suitable  ways  to  determine  which  subsets  of  the  design  might 
have  been  affected  by  a  given  change;  thus  one  cannot  be  sure  that  anything  less  than  full  testing 
will  suffice.  Techniques  are  required  to  assist  the  designer  in  making  such  a  determination. 

This  problem  is  a  chief  reason  that  information  hiding  was  developed  in  the  software 
domain.  An  extension  of  information  hiding  to  VLSI  design  that  would  address  this  problem 
requires  that  an  abstract  interface  be  specified  at  the  boundaries  of  each  design  component  to 
which  change  effects  are  to  be  localized.  The  existence  of  such  a  specification  would  reduce  test¬ 
ing  of  any  changed  design  to  the  assurance  that  each  changed  module  continued  to  meet  its  inter¬ 
face  specifications.  Even  if  such  interface  specifications  were  not  met,  the  affected  boundary 
modules  would  be  clearly  identified  for  follow-on  modification  and  testing. 
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l.S.t  Ditttrlation  Overview. 

The  dissertation  is  organized  as  follows.  Chapter  2,  after  defining  key  terms  and  criteria, 
summarizes  the  research  reported  in  the  literature  to  date  in  developing  methods  for  VLSI  design 
interface  specification.  In  chapter  3, 1  present  an  abstract  interface  specification  method,  an 
extension  of  Parnas's  software  specification  techniques.  I  do  not  contend  that  either  the  specific 
method  described,  or  the  notation  used  to  express  it,  is  optimal;  rather,  I  argue  for  the  desirability 
of  the  approach  thus  exemplified. 

Its  advantages  and  disadvantages  are  as  follows: 

—  The  approach  achieves  practical  scalability  to  VLSI  design  levels  through  precise  partitioning 
of  concerns  and  the  exploiting  of  abstraction:  the  complexity  of  the  specification  appears  to 
grow  slowly  with  design  scale.  Pressing  the  separation  of  concerns  to  the  ultimate,  I  made  a 
major  decision,  to  partition  module  semantics  per-pin  (instead  of  per-module,  as  is  conven¬ 
tional)  This  radical  partitioning  enhances  scalability,  complexity  control,  and  change 
management,  at  the  cost  of  making  it  somewhat  more  difficult  to  specify  constraints  global  to 
the  module. 

—  The  proposed  specification  starts  by  capturing  high-level  concerns  that  are  then  evolved  into 
more  particular  specifications  as  details  become  available  over  the  course  of  the  design.  The 
specification  not  only  evolves  in  detail,  it  remains  an  active  component  of  the  design,  subject 
to  intentional  revision  occasioned  by  new  insights  from  the  detailing. 

—  The  same  mechanisms  are  used  for  each  of  functional,  electrical,  and  geometric  information. 

—  A  new  technique  is  included  for  attaching  a  value  to  the  degree  of  specification  adherence  of  a 
candidate  module.  Using  this  technique,  the  specifier  can  communicate  knowledge  of  the  mar¬ 
ginal  utility  of  design  tradeoffs  to  the  implementer.  The  technique  is  complex,  however,  and 
needs  to  be  made  more  efficient  to  be  practical. 

The  proposed  interface  specification  method  consists  of: 

—  A  black-box  finite-state-machine  model,  together  with  a  generic  data  type  for  pin  and  internal 
state  variables  (the  generic  etate  type)  identifying  the  level  of  the  specification.  Specification 
refinement  corresponds  to  evolutionary  refinement  of  this  data  type.  Data  type  syntactic  and 
semantic  components  are  distinguished,  the  former  being  statically  verifiable  and  the  latter 
requiring  dynamic  verification.  This  partitioning  of  concerns  permits  further  simplification. 


—  Ad  extension  of  Parana's  aeceto  function  as  a  key  specification  element,  partitioning  module 
function  into  per-pin  components. 

—  Adherence  function $,  which  attach  a  value  to  the  degree  to  which  a  module  adheres  to  a  given 
specification.  Specification  adherence  is  defined  in  terms  of  a  Zadeh  fuzzy  set  [Zade75, 
Zade84j. 

I  next  discuss  sequencing  and  performance  issues  in  the  composition  of  such  specifications.  1 
show  how  access  functions  are  treated  as  “communicating  sequential  processes"  (CSP)  in  Hoare’s 
sense,  and  show  how  his  CSP  notation  can  be  used  to  express  these  functions.  1  also  address  four 
issues  relating  to  such  use  of  CSP: 

—  The  power  of  CSP  as  an  interface  specification  notation. 

—  Rules  of  thumb  for  expressing  data  and  control  pin  access  functions  in  CSP. 

—  The  degree  of  module  function  partitioning  that  can  be  attained  in  various  situations.  The 
worst  case  is  one  in  which  a  single  master  control  pin  effects  all  module  function. 

—  Requirements  of  a  base  language  for  implementing  CSP.  CSP  is  a  notation,  not  a  language. 

In  closing  chapter  3, 1  cite  specific  characteristics  of  the  VLSI  design  process  that  might  be 
used  to  simplify  specifications.  In  general,  these  involve  restrictions  on  the  general  model: 

—  Restriction  to  the  use  of  a  standard,  portable  base  language. 

—  Restriction  of  the  specification  refinement  hierarchy  to  certain  predefined  semantic  and  syntac¬ 
tic  levels,  promoting  reusability  of  generic  state  type  definitions. 

—  Restriction  of  the  adherence  function  space  to  a  set  of  standard  adherence  functions  (candi¬ 
dates  are  presented). 

In  chapter  4,  I  report  on  an  evaluation  of  the  proposed  abstract  interface  specification 
method  with  respect  to  the  criteria  established  in  chapter  2.  The  evaluation  is  based  on  experi¬ 
ence  with  a  set  of  four  real  small-  to  large-scale  IC  modules  which  were  specified,  using  the  pro¬ 
posed  method,  at  various  semantic  and  syntactic  refinement  levels.  These  specifications  are  pro¬ 
vided  in  an  appendix. 

—  To  evaluate  the  perceived  co6t-effectiveness  (scalability)  of  the  method  at  VLSI  design  levels,  I 
consider  specification  size  as  a  function  of  design  size.  The  data  suggest  that  this  specification 
approach  is  feasible  for  very-large-scale  designs. 


To  test  the  life-cycle  integration  of  the  method,  1  first  measure  the  relative  amount  of  change 
in  the  test  specifications  as  they  are  refined,  finding  that  a  significant  fraction  of  each  test 
specification  is  preserved  unchanged  through  refinement. 

To  examine  the  spareness  of  the  method,  I  informally  review  each  of  its  elements  for  overlap 
with  the  others. 

To  estimate  the  method’s  effectiveness  in  managing  change,  I  conduct  a  series  of  experiments. 
The  first  demonstrates  the  robustness  of  subordinate  specifications  when  a  parent  specification 
is  changed.  The  second  illustrates  the  conditions  under  which  specification  changes  affect 
nearby  modules.  In  the  third,  real-world  changes  are  applied  to  an  actual  specification  with 
only  minor  effects. 

Chapter  5  contains  conclusions  and  suggestions  for  future  research. 
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CHAPTER  2 

SURVEY  OF  PREVIOUS  RESEARCH 

The  previous  chapter  suggested  that  effective  techniques  for  specification  of  abstract  VLSI 
design  interfaces  would  help  manage  change  in  the  VLSI  design  process.  This  chapter  will 
describe  and  evaluate  the  effectiveness  of  existing  VLSI  design  interface  specification  methods. 

Some  historical  background  will  place  this  survey  in  context.  A  rough  parallel  can  be  drawn 
between  the  evolution  of  design  methodologies  for  software  and  for  integrated  circuits,  although 
the  paths  are  offset  in  time  by  perhaps  10-15  years.  In  the  software  community,  there  was  little 
recognition  of  the  importance  of  specifications  before  system  complexity  exceeded  manageable 
bounds.  Even  now  (as  Yeh  [Yeh83]  observes),  certainly  not  all  software  designers  have  internal¬ 
ized  the  recognition  that  the  complexity  of  modern  systems  is  truly  beyond  their  intellectual  span 
of  control.  One  expects,  therefore,  a  parallel  reluctance  by  IC  designers  to  admit  that  complexity 
has  become  overwhelming.  Because  MSI  and  LSI  complexity  levels  do  not  compel  an  emphasis  on 
specification,  "specification"  and  "interface”  are  terms  that  have  yet  been  mentioned  only  infre¬ 
quently  in  the  IC  design  literature. 

This  is  not  to  say  that  the  specification  and  interface  definition  functions  have  not  been  per¬ 
formed  in  IC  design,  or  even  in  VLSI  design.  These  functions,  however,  have  been  called  by 
different  names,  leading  to  some  semantic  confusion.  To  define  them  clearly  here,  I  will  first  pro¬ 
vide  a  model  of  the  VLSI  design  process,  a  model  that  will  show  the  role  of  VLSI  design  interface 
specifications.  Based  on  this  model,  I  will  define  "VLSI  design  abstract  interface  specification." 
Finally,  I  will  survey  the  important  published  work  that  has  been  done  so  far  in  developing  VLSI 
design  interface  specification  techniques. 

2.1  Definitions. 

2.1.1  The  Integrated  Circuit  (1C)  Design  Process;  the  VLSI  Design  Process. 

Definitions.  The  IC  design  process  is  a  sequence  of  elaborations  that  synthesize,  from  a  design 
concept,  a  form  suitable  for  fabrication.  The  VLSI  design  process  is  the  IC  design  process  applied 
to  the  design  of  very-large-scale  circuits. 


Ditcutrion.  Figure  2-1  illustrates  a  hierarchical  model  of  the  contemporary  IC  design  process. 

The  designer  starts  with  a  concept,  either  of  the  complete  system  or  of  a  system  component.  The 
goal  of  the  design  is  a  description  of  the  design  in  a  form  suitable  for  fabrication  [Trim8lj.  To 
manage  complexity,  the  designer  subdivides  the  monolithic  concept- to-fabrication  transformation 
into  a  sequence  of  elaboration  steps,  the  result  of  elaboration  (oyntherie)  at  each  each  step  being 
an  intermediate  representation  (or  “description”;  cf.  [Lehm84]).  Each  representation,  then,  con¬ 
tains  more  information,  in  Shannon’s  sense  [Shan49|,  than  its  predecessor;  it  serves  as  a  milestone 
in  the  descent  of  a  tree  of  potential  designs  that  could  be  developed  from  the  original  concept. 
Representations  frequently  employed  in  IC  design  are,  for  example,  the  Boorplan,  the  logic 
diagram,  the  layout,  and  so  on;  each  embodies  additional  information  about  the  design. 

Synthesis  and  representation,  however,  are  not  the  only  activities  that  take  place  at  each 
elaboration  step.  Two  additional  activities  —  verification  and  evaluation  —  are  required  at  each 
step  to  ensure  the  accurate  progress  of  the  design  effort  (Figure  2-2).  Redoing  the  current  step  or 
backtracking  to  a  previous  step  may  be  required. 


Designer’s  Concept 


Representation  1 


Representation  2 

I 


Representation  n 


Form  Suitable  for  Fabrication 


Figure  2-1.  The  IC  Design  Process. 


The  IC  design  process,  therefore,  is  the  hierarchies!  repetition,  possibly  with  backtracking, 
of  the  four  steps  defined  in  Figure  2-2.  Furthermore,  in  the  IC  system  design  process,  Figure  2-1 
should  be  visualized  as  being  replicated  many  times,  once  for  each  design  component  (such  as  a 
cell),  so  that  a  representation  of  the  total  design  consists  of  a  compatible  set  of  representations  for 
all  components. 

The  definition  of  the  VLSI  design  process  correctly  identifies  its  component  activities  as  the 
same  as  those  for  IC  design.  As  I  noted  in  chapter  1,  however,  “VLSI  design  is  IC  design  in  which 
brute  force  no  longer  works."  The  requirement  for  using  complexity  management  techniques  in 
the  design  elaborations  distinguishes  VLSI  design  from  IC  design  at  lesser  levels  of  integration. 

S.l.S  Interface;  Abstract  Interface. 

Definitions.  An  interface  (between  two  design  modules)  is  the  set  of  assumptions  that  each 
module  designer  needs  to  make  about  the  other  module  to  demonstrate  the  correctness  of  his/her 
own  module.  An  abstract  interface  is  an  interface  containing  no  assumptions  about  the  internal 
composition  of  the  module. 


—  Synthesis:  the  elaboration  of  one  level  of  description  into  the  next  lower  level. 

—  Description:  the  construction  of  an  abstract  model  of  a  system  (a  representation )  that  details 
properties  specific  to  a  given  purpose. 

—  Verification :  a  8emi-formal  process  whereby  the  design  at  a  particular  level  is  shown  to  be 
equivalent,  in  either  behavior  or  structure  [or  Koth],  to  one  or  more  higher-level  designs. 

—  Evaluation:  the  assessment  of  the  degree  to  which  the  design  meets  (1)  physical  and  perfor¬ 
mance  requirements  and  constraints;  and  (2)  criteria  of  behavioral  and  structural  complete¬ 
ness. 


Figure  2-2.  Activities  Performed  at  an  IC  Design  Step. 
[Boeh81,  Latt81,  Dall83] 


Discussion.  Recall  the  definition  of  “interface"  given  in  chapter  1:  “the  set  of  assumptions  that 
each  programmer  needs  to  make  about  the  other  program  to  demonstrate  the  correctness  of 
his/her  own  program."  Replacing  “programmer"  with  “designer"  and  “program”  with  “design” 
yields  a  definition  appropriate  to  the  IC  design  process.  Also  from  chapter  1,  recall  that  an 
“abstract"  interface  specification  has  the  additional  property  that  the  specification  mnst  not  con* 
tain  assumptions  about  the  internal  composition  of  the  module  (its  implementation). 

Nearly  every  representation  of  an  IC  design  component  is  an  interface  specification,  in  that 
it  provides  the  basis  for  other  designers  to  draw  some  interface  assumptions.  For  example,  a  logic 
diagram  is  frequently  used  as  an  interface  specification,  because  it  is  believed  that  most  designers 
can  infer  the  interface  from  the  diagram.  But,  for  the  reasons  noted  earlier,  such  representation* 
based  (or  “clear*box")  specification  techniques  are  inadequate  at  VLSI  complexity  levels. 

Much  less  frequently  are  abstract  interface  specifications  encountered  in  IC  design.  Britton, 
Parker,  and  Parnas's  research  [BritSla]  demonstrates  that  specifying  an  abstract  interface  is  a 
deceptively  difficult  process:  identifying  and  precisely  specifying  all  the  essential  assumptions 
making  up  an  interface,  without  over-constraining  the  definition  with  excess  or  improper  assump¬ 
tions,  require  both  substantial  knowledge  of  the  project  and  of  the  underlying  technologies. 
Nevertheless,  I  do  not  believe  that  VLSI  designers  can  deal  effectively  with  complexity  and  change 
until  good  abstract  interface  specification  techniques  are  developed. 

£.1.8  Frame;  Specification. 

Definitions.  A  frame  is  a  design  description  assumed  to  be  correct  in  all  that  it  states  or  implies 
about  the  design.  A  specification  is  a  highest-level  (therefore  unverifiable)  description  that  serves 
as  a  frame  for  subsequent  verification  activities. 

Discussion.  Dallen  |Dall83]  provides  a  good  general  definition  of  the  term  specification:  “an  ideal¬ 
ized  abstraction  of  the  system  being  designed."  Wbat  is  the  role  of  a  specification  in  the  design 
process,  however?  Lehman,  Stenning,  and  Turski  [Lehm84]  identify  it,  once  again  in  the  context 
of  the  software  domain,  when  they  state: 

Calculability  of  program  correctness  implies  that  'correctness'  is  not  an  attribute  a  program  may 
or  may  not  possess  when  considered  in  isolation.  An  external  frame  of  reference  must  be  provided 
with  respect  to  which  the  calculations  are  meaningful.  This  frame  of  reference  for  establishing 
correctness  of  a  program  is  often  referred  to  as  a  specification. 


I  have  shortened  Lehman,  Stenning,  and  Tarski's  phrase  “frame  of  reference  for  establishing 
correctness”  simply  to  the  word  frame.  A  physical  frame  both  constrains  and  allows  freedom 
within  its  constraints;  thus  it  is  an  accurate  model  of  a  specification. 


Supporting  this  interpretation,  Levene  and  Mullery  [Leve82j  identify  the  role  of  a 

specification  from  a  traditional  administrator’s  viewpoint,  but  still  define  it  as  a  frame: 

—  [A  specification]  should  clearly  indicate  what  the  intended  system  is  to  do,  including  interaction 
with  other  systems,  people,  media,  and  devices,  in  terms  that  the  customer  or  users  can  under¬ 
stand; 

—  It  should  be  a  complete  specification  for  the  purposes  of  the  development  agency.... 

—  While  it  is  being  produced,  the  partial  specification  document  can  be  ...  referenced  Tor  use  in 
developing  other  parts.  This  will  also  allow  it  to  be  maintained  whenever  the  need  for  changes 
is  recognised,  either  during  the  development  of  the  proposed  system  or  later  during  its  operas 
tional  life. 

Parnas  [Parn77a]  also  acknowledges  the  role  of  specification  as  frame  when  he  asserts  that  a 

specification  is  necessary 

—  To  describe  the  problem  to  be  solved. 

—  For  communication  between  software  engineers. 

—  To  free  the  programmer  from  needing  to  know  how  the  rest  of  the  system  works. 

—  To  support  the  development  of  multi-version  software. 

—  To  complete  the  description  of  intermediate  design  decisions  (encapsulated,  for  example,  in  the 
abstract  primitives  that  make  up  high-level  representations  in  Figure  2-1]. 

—  To  permit  verification  of  intermediate  design  decisions. 

A  specification,  then,  is  that  abstract  description  of  a  system  that  provides  a  frame  for  system 

verification,  for  answering  the  question  “Did  we  build  the  product  right?”  [Boeh8l] 


Since,  as  I  have  noted,  the  word  “specification”  is  infrequently  used  in  a  VLSI  design  con* 
text,  what  part  of  the  VLSI  design  model  is,  by  virtue  of  addressing  these  purposes,  a  de  facto 
specification?  Consider  the  initial  (top-level)  steps  in  the  model  of  VLSI  design  developed  in  sec¬ 
tion  2.1.1.  Figure  2-3  expands  these  initial  steps  into  their  four  component  activities.  One  of 
these  activities  must  be  the  synthesis,  from  the  (undescribed)  designer’s  concept,  of  a  highest-level 
description  of  the  design,  a  description  that  cannot  be  verified  since  there  is  no  description  against 
which  it  can  be  verified.  It  is  this  highest-level,  unverified  description  that  I  call  the  specification 
of  the  VLSI  design,  and  it  is  this  description  that  serves  as  a  frame  for  verification  activities.1 


1  Thu  i*  sot  to  »y  that  lower-level  descriptions  cannot  be  takes  out  of  their  context  is  one  design  hierarchy 
(Figore  2-1)  sad  seed  as  specifications  in  another.  For  example,  a  logic  diagram  might  not  be  a  specification  in  the 
context  of  a  complete  design  bat  might  serve  as  one  in  a  subset  of  that  design  activity  (a  separate  instantiation  of  Figure 
2-1) 
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Figure  2-3.  Expansion  of  the  VLSI  Design  Process 
at  its  Highest  Levels. 

Many  different  types  of  specification  exist.  The  following  list  describes  some  distinguishing 
characteristics  important  for  VLSI  designs. 

(1)  Informal  vs.  Formal.  A  specification  is  usually  called  formal  if  both  the  syntax  and  semantics 
of  its  primitives  are  mathematically  precise,  that  is,  strictly  and  unambiguously  defined  [Lisk79]. 
Formality  and  precision  iu  specifications  are,  therefore,  intertwined.  Parnas  [Parn77a]  concedes 
that  a  specification  can  be  precise  without  being  formal  but  notes  that  creating  one  is  "very 
difficult.”  By  definition,  the  converse  is  not  true:  a  formal  specification  is  always  precise. 

Sometimes  added  is  the  stipulation  that  a  formal  specification  must  contain  the  capability 
to  demonstrate  rigorously  the  validity  of  implementation  objects  derived  from  it  [Cohe83, 
Lehm84|.  In  my  view,  this  overconstrains  the  definition,  however  desirable  such  a  capability  may 
be. 

(t)  Syntactic  vs.  Semantic.  Wegner  [Wegn84]  differentiates  syntactic  and  semantic  interface 
specifications  of  software  components  as  follows:  “Syntactic  interfaces  specify  compile-time  invari¬ 
ants  that  determine  how  components  fit  together,  while  semantic  interfaces  specify  execution-time 
invariants  that  determine  what  the  component  computes.”  A  similar  concept  exists  for  IC 
modules:  the  syntax  (well-formedness)  of  a  composition  of  modules  can  be  checked  statically  (i.e., 
without  recourse  to  dynamic  analysis  or  simulation),  whereas  the  semantic  integrity  of  a  module 
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composition  requires  dynamic  verification.  Syntactic  specifications,  therefore,  are  adequate  to 
determine  the  consistency  (but  not  the  validity)  of  a  proposed  module  interconnection.  As 
Wegner  notes, 

strong  semantic  interface  specifications  are  intractable  in  the  sense  that  they  do  not  always  exist 
and  their  correctness  cannot  always  be  verified. ...  The  trade-offs  between  the  flexibility  and 
efficiency  of  very  weak  interface  specifications  and  the  guaranteed  integrity  of  strong  interface 
specifications  need  to  be  better  understood. 

(S)  Non-executable  vs.  Executable.  A  specification  is  called  executable  if  it  is  possible  to  create  a 
machine  interpretation  of  the  specification  that  provides  an  approximation  of  external  system 
behavior  (Zave84j.  Because  of  their  precise  syntax  and  semantics,  all  formal  specifications  can  be 
meaningfully  processed  by  a  computer  [Lisk79j;  however,  not  all  formal  specifications  contain  the 
kinds  of  behavioral  semantics  necessary  to  permit  simulation  of  system  behavior  by  machine  pro¬ 
cessing. 

An  extreme  (and  sometimes  overconstraining)  form  of  executable  specification  is  a  realiza¬ 
tion  of  the  desired  design:  when  questions  of  specification  details  arise,  one  “asks  the  machine”  by 
making  an  experimental  query  of  the  existing  realization  [Broo75|. 

(4)  Black-Box  vs.  Clear-Box.  Earlier,  a  clear-box  (sometimes  called  structural)  specification  of  a 
module  interface  was  characterized  as  one  that  prescribed  the  interface  indirectly  by  describing  an 
implementation  of  internal  module  structure,  logic,  or  circuitry.  A  black-box  (or  behavioral) 
specification,  on  the  other  hand,  prescribes  a  module  interface  through  a  description  of  the 
module’s  externally  visible  behavior  [Zave84|.  Somewhat  generally,  I  referred  to  a  black-box 
interface  specification  as  an  abstract  interface  specification,  in  that  for  a  given  black-box 
specification  more  than  one  implementation  (of  the  type  prescribed  in  a  clear-box  specification) 
could  exist. 

This  distinction  is  perhaps  too  clearly  drawn.  Proponents  of  clear-box  specification  might 
6tate  that  the  implementation  they  produce  is  not  meant  to  constrain  the  implementation,  but 
merely  to  prescribe  its  behavior.  Indeed,  this  implementation  itself  could  be  abstract,  describing 
module  behavior  executably  but  in  terms  of  implementation-independent  substructures  |Zave84j. 
Zave  calls  a  specification  that  describes  module  behavior  in  such  a  way  an  operational 
specification.  In  contrast,  &  functional  or  input/ output  specification  describes  a  direct  functional 
relationship  among  module  inputs  and  outputs  without  reference  to  substructures  [Lisk79|.  For 
this  dissertation,  an  (abstract)  operational  specification  is  also  a  black-box  specification,  but  a  so- 
called  operational  specification  that  prescribes  an  implementation  is  neither  black-box  nor  opera¬ 
tional. 
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Id  this  dissertation,  I  will  thus  not  join  the  debate  between  proponents  of  operational  and 
functional  specifications.  The  crucial  issue  is  that  both  types  can  specify  interfaces  abstractly, 
and  I  contend  that  such  specification,  which  I  cal)  black-box,  is  superior  to  its  clear-box  counter¬ 
part  Furthermore,  in  the  hardware  domain  much  of  what  passes  for  operational  specification,  as 
Zave  defines  it,  is  in  practice  clear-box  specification. 

t.l .4  Module  Function;  Module  Performance. 

Definitions.  The  function  of  an  1C  module  is  its  externally  visible  behavior.  The  performance  of 
an  1C  module  is  a  set  of  measurements  of  its  function  in  terms  of  physical  phenomena  (e.g.  speed, 
power,  area). 

Discussion.  The  word  “functional"  is  overloaded  in  specification  parlance.  In  distinction  from 
the  use  made  of  it  in  the  previous  section  as  an  opposite  to  “operational,"  it  can  also  be  used  to 
differentiate  the  semantics  contained  in  the  specification. 

In  software,  Liskov  and  Berzins  [Lisk79]  state  that  "functional”  specifications  “describe  the 
effect  of  the  module  on  its  external  environment,"  whereas  "performance”  specifications  “describe 
constraints  on  the  speed  and  resource  utilization  of  the  module."  In  IC  design,  however,  the  effect 
of  the  module  on  its  external  environment  depends  on  its  performance,  so  that  the  line  between 
functional  and  performance  specifications  must  be  redrawn.  Indeed,  it  is  possible  to  think  of  a 
single  function/performance  continuum,  corresponding  to  a  continuum  of  abstraction  of 
specification  primitives.  I  will  treat  this  issue  in  detail  during  the  discussion  of  adequacy  in  sec¬ 
tion  2.2.2. 

Other-than-functional  specifications  are  sometimes  called  constraints.  Roman  [Roma85],  in 
a  recent  taxonomy  of  software  requirements  engineering  issues,  enumerates  several  constraints 
besides  performance:  interface  constraints  (assumptions  about  the  environment),  operating  con¬ 
straints  (size,  weight,  power,  etc.),  life-cycle  constraints  (maintainability,  enhanceability,  portabil¬ 
ity,  development  time  limitations,  etc.),  economic  constraints,  and  political  constraints.  For  the 
purposes  of  the  current  VLSI-oriented  work,  Roman’s  interface  constraints  are  considered  to  be 
orthogonal  to  the  functional/performance  issue;  operating  constraints  are  considered  together  with 
performance  constraints;  and  the  other  three  types  of  constraints  can  be  dealt  with  only  infor¬ 
mally. 


t.1.5  Abstract  VLSI  Interface  Specification. 


Definition.  An  abstract  VLSI  interface  specification  is  a  reduced  set  of  assumptions  that  a 
designer  of  an  adjacent  VLSI  module  would  need  to  make  to  design,  and  especially  to  verify  the 
correctness  of,  this  adjacent  module.  This  set  is  reduced  in  that  it  excludes  assumptions  that 
have  to  do  with  internal  module  implementation. 

S.S  Requirements  for  VLSI  Design  Abstract  Interface  Specifications. 

In  this  section,  I  shall  enumerate  the  requirements  that  an  abstract  interface  specification 
must  meet  in  the  VLSI  design  process.  Later,  I  shall  examine  existing  specification  methods  in 
light  of  these  requirements. 

S.S.l  Provision  of  Frame  for  Verification  (Adequacy). 

This  requirement  follows  directly  from  the  definition  of  “specification”  developed  in  section 
2.1.3.  A  description  purporting  to  be  a  specification  must  be  a  specification:  it  must  provide  a 
frame  for  both  technical  and  administrative  verification.  (To  the  extent  that  these  types  of 
verification  differ,  technical  verification  focuses  on  technical  performance  of  the  product,  while 
administrative  verification  examines  the  product  for  fulfillment  of  relevant  contractual  obliga¬ 
tions.) 


Design  specifications  can  be  constructed  at  differing  degrees  of  what  I  have  chosen  to  call 
adequacy.  That  is,  there  exists  a  continuum  (Figure  2-4)  of  refinement  of  the  amount  of  detail 
included  in  the  specification.  At  the  coarsest  levels,  a  specification  may  be  given  in  general  terms, 
e.g.  “this  module  is  the  ALU."  Refinement  of  this  specification  along  the  continuum  of  Figure  2-4 
gradually  adds  detail  to  the  specification,  until  at  some  point  in  the  continuum  there  is  an  ade¬ 
quate  level  of  detail  to  guide  the  implementation.  At  this  point,  which  is  admittedly  vaguely 
defined,  it  can  be  said  that  the  specification  is  adequate. 

Liskov  and  Benins  (Lisk79)  distinguish  two  types  of  specifications:  functional  and  perfor¬ 
mance.  With  respect  to  these  two  types  of  specification,  the  experiences  of  software  and  hardware 
engineering  differ.  In  software  engineering,  functional  specifications  are  of  chief  importance, 
because  performance  issues  are  largely  orthogonal  to  function  and  thus  can  be  abstracted  away;  if 
better  performance  is  needed,  one  can  tune  the  implementation  later  or  get  a  faster  machine. 
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Figure  2-4.  Continuum  of  Specification  Refinement. 


Two  separate  continua  of  refinement  (Figure  2-4),  one  each  for  function  and  performance,  thus 
exist  in  software  specification. 

In  hardware  engineering,  however,  a  well-known  adage  states:  “Circuits  must  not  only  work; 
they  must  perform."  In  hardware  design,  what  is  functionally  correct  under  less  specific 
parametric  or  performance  constraints  may  cease  to  be  functionally  correct  under  more  specific 
constraints;  thus  function  and  performance  are  naturally  intertwined.  Because  of  this  characteris¬ 
tic  of  hardware  engineering,  then,  in  IC  design  what  is  called  a  functional  specification  can  be 
interpreted  as  an  early  stage,  and  performance  specification  as  a  later  stage,  of  a  single 
specification  refinement  continuum.  At  all  levels  of  refinement  the  specification  must  be  precise; 
the  primitives  with  which  it  is  described,  however,  may  vary  in  specificity.  The  adequacy,  then, 
of  an  IC  design  abstract  interface  specification  depends  on  the  specificity  of  its  performance  con¬ 
straints  relative  to  the  specificity  required.  If  one’s  concern  is  merely  that  the  circuit  function 
correctly  at  some  level  of  performance,  then  a  less  detailed  (functional)  specification  will  be  ade¬ 
quate.  But  if  one’s  concern  is  that  the  circuit  function  correctly  at  an  intended  level  of  perfor¬ 
mance,  a  more  refined,  more  detailed  specification  will  be  needed. 


In  VLSI  design  in  particular,  concern  for  correct  behavior  at  intended  performance  levels  is 
of  central  importance.  Ultimately,  then,  a  VLSI  design  interface  specification  must  contain  per¬ 
formance  detail.  This  requirement  implies,  because  of  the  inseparability  of  performance  from  a 
design’s  geometric  and  electrical  characteristics,  that  these  latter  characteristics  must  also  be 
included.  As  a  result,  a  substantial  variety  of  information  is  required  in  a  VLSI  design  abstract 
interface  specification,  and  the  specification  technique  employed  should  both  (1)  provide  rich 
enough  facilities  to  express  this  information  and  (2)  express  it  in  terms  of  the  performance  levels 
required. 

Shaw  [Shaw84]  has  recently  elaborated  on  this  requirement  as  follows: 

A  specification  methodology  that  addresses  [properties  other  than  pure  functional  correctness] 
must  have  two  important  characteristics.  First,  it  must  be  possible  for  the  programmer  to  make 
and  verify  assertions  about  the  properties  rather  than  simply  analysing  the  program  text  to  derive 
exact  values  or  complete  specifications.  This  is  analogous  to  our  approach  to  functional 
specifications  —  we  don't  attempt  to  formally  derive  the  mathematical  function  defined  by  a  pro¬ 
gram;  rather,  we  specify  certain  properties  of  the  computation  that  are  important  and  must  be 
preserved.  Further,  it  is  important  that  the  specification  methodology  avoid  adding  a  new  concep¬ 
tual  framework  for  each  new  class  of  properties.  This  implies  that  mechanisms  for  dealing  with 
new  programs  should  be  compatible  with  the  mechanisms  already  used  for  functional  correctness. 

S.S.S  Spareness. 

Parsimony,  that  is,  limiting  the  number  of  related  expressive  mechanisms  in  a  specification 
technique,  is  clearly  desirable.  It  might  fruitfully  be  thought  of  as  an  aspect  of  a  more  general 
economy,  which  I  shall  call  spareness.  Spareness  is  the  property  of  a  specification  that  implies 
that  it  says  only  what  it  needs  to  say. 

As  Parnas  has  noted  [Parn72a,  Parn77a],  what  a  specification  does  not  contain  is  nearly  as 
important  as  what  it  does  contain.  It  is  vitally  important  not  to  clutter  the  specification  ith 
extraneous  requirements:  these  not  only  over-constrain  the  implementer  but  also  slow  comprehen¬ 
sion  |Meye85).  Thus  a  spare  abstract  interface  specification  technique  must  not  only  manifest 
economy  of  expression,  but  it  must  also  identify  which  details  are  essential  and  which  are 
unnecessary. 

S.S.S  Perceived  Cost-Effectiveness. 

The  desirability  of  spareness  is  but  one  illustration  that  the  usefulness  of  a  specification  is 
strongly  related  to  its  intuitive  appeal  to  designers,  that  is,  the  degree  to  which  the  specification 
technique  is  perceived  as  cost-effective.  Clarity  and  simplicity,  as  Liskov  and  Berzins  |Lisk79] 


have  pointed  out,  contribute  significantly  to  a  specification  technique’s  attractiveness.  Choosing 
familiar  representations  also  aids  acceptance  [Lisk79],  Finally,  the  costs  of  using  the  method  need 
to  be  reduced  as  much  as  feasible:  a  clumsy  or  slow  user  interface  is  certain  to  undercut  adoption 
of  a  proposed  technique,  especially  considering  that  designers  have  not  yet  embraced  specification 
methods  per  se.  Baroque  and  unusable  specification  methods  are  all  too  easy  to  develop:  Liskov 
and  Zilles  [Lisk75j  called  difficulty  in  use  “the  fundamental  problem  with  specifications.” 

t.S.4  Malleability. 

A  strong  contributing  factor  in  the  perceived  cost-effectiveness  of  a  specification  is  its  useful¬ 
ness  throughout  the  design  life- cycle.  What  quality  of  a  specification  contributes  to  such  useful¬ 
ness? 

A  valuable  but  elusive  goal  in  design  is  that  of  getting  the  specification  “correct”  the  first 
time  through  careful  axiomatic  thinking.  Several  noted  contemporary  scientists,  such  as  Dijkstra, 
believe  that  such  a  goal  is  achievable  [Berg81],  and  they  may  ultimately  be  proven  right.  For  the 
present,  however,  specifiers  do  not  always  seem  to  be  able  to  foresee  the  later  emergence  of 
difficulties  and  even  contradictions  in  the  specification  constraints  they  have  established  at  the 
outset.  If  these  specification  constraints  are  rigid,  backtracking  that  includes  constraint 
modification  would  be  impossible. 

Perhaps,  then,  it  is  unfruitful  to  visualize  specification  constraints  as  being  rigid.  Instead, 
the  constraints  might  better  be  viewed  as  variables,  albeit  with  "stiff”  coefficients  of  elasticity. 
(Other  variables  have  more  pliable  coefficients.)  I  call  the  degree  to  which  a  specification's  con¬ 
straints  can  be  viewed  as  variables  its  malleability,  and  I  contend  that  malleability  enhances  the 
life-cycle  utility  of  a  specification.  Malleability  is  not  imprecision;  it  is  the  property  of  a 
specification  that  permits  and  facilitates  precise  constraint  adjustment  as  necessary,  in  the 
interest  of  preserving  the  usefulness  of  the  specification  as  a  frame  for  verification  throughout  the 
design  life-cycle. 

Good  examples  of  malleable  specifications  are  the  incremental  (prototype-based)  [Myer84] 
and  transformation-based  [Balz83,  Part83]  life-cycle  paradigms,  as  contrasted  to  the  conventional 
linear  development  model.  Such  methods  depend  on  regular  incorporation  of  feedback  into  the 
specification,  which  is  then  used  directly  to  derive  refined  systems.  The  appeal  of  these  non- 
conventional  approaches  may  indeed  be  due  largely  to  their  increasing  the  usefulness  of  the 


system  specification  in  the  design  life-cycle. 
t.t.S  Change  Management  Support. 

Finally,  as  has  been  noted  in  chapter  1,  a  primary  motivation  for  developing  a  new  VLSI 
design  interface  specification  method  is  to  support  change  management.  To  do  this,  an  ideal 
specification  technique  should  assure  the  designer  that  internal  changes  to  a  design  module  that 
do  not  change  the  specification  also  do  not  have  effects  outside  the  boundaries  of  that  module. 
This  requirement  thus  overlaps  the  requirements  of  the  preceding  sections,  especially  those  for 
adequacy  and  malleability. 

£.8  Existing  VLSI  Design  Interface  Specification  Methods. 

No  technique  fully  meeting  the  five  requirements  enumerated  in  the  preceding  section  has 
yet  been  developed.  At  this  point,  I  will  review  the  important  published  work  that  has  been  done 
in  developing  methods  for  constructing  VLSI  design  interface  specifications.  It  is  important  to 
note  that  all  the  specification  methods  to  be  surveyed  have  a  place  in  the  design  process;  however, 
I  shall  evaluate  them,  using  the  criteria  of  section  2.2,  specifically  as  candidates  for  interface 
specification  methods  to  support  change  management. 

£.8.1  Methods  for  Informal  Specification. 

Informal  specifications  of  IC  interfaces  are  most  often  an  ad  hoc  mixture  of  prose  descrip¬ 
tions  and  block  diagrams,  intended  to  convey  the  function  and/or  structure  of  the  design  to  a 
general  audience.  Procedures  for  informal  specification  rarely  receive  wide  dissemina'ion. 

£.8.1.1  Examples. 

—  Lattin  el  al.  [Latt8l]  mention  a  "200-page  document”  that  served  as  the  specification  for  the 
Intel  iAPX-432  design  and  that,  judging  from  the  context,  was  probably  at  least  partly  infor¬ 
mal.  Indeed,  it  is  reasonable  to  surmise  that  mo6t  major  chip  design  projects  begin  with  such 
a  document. 


—  Standard  cell  system  documentation  usually  includes  an  informal  description  of  cell  interfaces. 
Module  interfaces  in  the  Stanford  Cell  Library  (Newk83),  for  example,  are  described  both  in 
prose  and  in  a  formal  mask  description  that  can  be  simulated  to  provide  more  precise  interface 
data.  Informal  specifications  similarly  are  included  in  documentation  of  those  silicon  compiler 
systems  [Gros83aj  that  are  based  on  parameterized  standard  cells,  such  as  the  Concorde  Sys¬ 
tem  of  Seattle  Silicon  Technology,  Inc.  (SST84). 

B.S.l.S  Strengths/ Weaknesses. 

Britton,  Parker,  and  Parnas  [Brit81a]  identify  the  strength  of  informal  specifications:  they 
are  easy  to  review  for  people  not  intimately  familiar  with  the  technical  details  of  the  project. 

Since  most  specifications  require  approval  by  persons  in  this  category,  Britton,  Parker,  and  Parnas 
suggest  that  software  specification  methods  should  accommodate  an  informal  component  that 
embodies  those  assumptions  critical  to  the  design  and  that  is  consistent  with  the  formal  portion  of 
the  specification. 

Unless  they  are  supplemented  by  a  formal  component,  however,  informal  specifications  are 
inadequate  to  provide  a  verification  frame  in  the  design  of  complex  systems,  for  the  reasons  listed 
by  Dasgupta  |Dasg84]: 

—  The  dynamic  aspects  of  the  architecture  ...  are  usually  specified  incompletely.  [This  is  particu¬ 
larly  true  in  IC  module  interface  specification,  since  the  interface  is  semantically  rich,  with 
functional,  electrical,  and  geometrical  components,  and  an  informal  specification  is  usually 
truncated  for  manageability  before  all  these  data  are  included.] 

—  It  is  extremely  difficult,  even  in  principle,  for  the  design  to  be  validated  for  correctness  without 
constructing  and  testing  the  physical  system. 

—  The  sequence  of  design  decisions  and  the  rationale  for  them  are  seldom  documented  explicitly. 

...  It  is  virtually  impossible  to  investigate,  manipulate,  or  alter  a  design,  or  evaluate  alterna¬ 
tive  architectures  for  performance  characteristics,  without  constructing  and  testing  the  physical 
system.  [Heninger  [Heni78]  blames  this  lack  of  robustness  not  only  on  the  intractability  of  in¬ 
formal  specifications  but  also  on  their  frequent  failure  to  include  fundamental  assumptions,  re¬ 
quired  subsets,  expected  changes,  and  rules  for  treatment  of  undesired  events.] 

The  inherent  weaknesses  of  informal  specifications  as  stand-alone  system  specifications  are  dis¬ 
cussed  in  greater  length  by  Meyer  ]Meye85], 

S.S.S  Methods  for  Syntactic  Specification. 

Syntactic  interface  specifications  exist  for  verifying  the  integrity  of  a  composition  of 
modules;  they  are  of  most  value  when  such  verification  is  complex. 


2.S.S.1  Examples. 


The  best  examples  of  syntactic  IC  module  interface  specification  are  “pin-typing"  schemes. 
Slgal  [Sfga^l]  was  among  the  first  to  demonstrate  such  a  technique,  but  his  effort  was  abandoned 
because  of  incompatibility  with  other  existing  tools.  Noice,  Mathews,  and  Newkirk  (Noic82) 
reported  on  the  benefits  of  using  signal-labeling  conventions  in  the  two-phase  nMOS  clocking  dis¬ 
cipline  described  by  Mead  and  Conway  [Mead80];  Karplus  [Karp84]  extended  their  work  and  pro¬ 
vided  a  formal  basis  for  it.  Some  success  with  a  related  scheme  using  a  different  set  of  restrictions 
has  been  reported  by  Poulton  [Pou  184].  Although  he  has  so  far  used  only  manual  verification  of 
the  embedded  information,  his  method  is  compatible  with  existing  design  tools  and  has  been 
reported  to  aid  design  composition  significantly  in  more  than  one  project  involving  multiple  clocks 
|Poul85],  Newkirk  and  Mathews  [Newk83]  and  the  designers  of  the  VIVID  system  [Rose84]  have 
provided  some  syntactic  pin-typing  facilities  in  their  respective  design  tools;  no  results  analyxing 
their  usefulness  have  yet  been  reported. 

£.8.2.2  Strengths/  Weaknesses. 

In  the  previously-cited  quote,  Wegner  |Wegn84]  stated  correctly  that  although  syntactic 
interface  specifications  are  easier  to  create,  it  is  usually  in  verifying  semantics  that  a  verification 
frame  (a  specification)  is  most  required.  Consequently,  purely  syntactic  IC  interface  specification 
techniques  have  not  yet  generated  much  interest,  except  in  designs,  such  as  Poulton 's,  of 
significant  syntactic  complexity. 

2.8.8  Methods  for  Non-Executable  Specifications. 

Because  informal  interface  specifications  have  already  been  considered,  I  shall  examine  only 
formal,  non-executable  specifications  here.  There  have  been  two  distinct  formal,  non-executable 
approaches,  which  now  appear  to  be  joining  in  a  confluence  of  thought.  The  first  approach  pro¬ 
vides  a  formal  high-level  description  of  both  behavior  and  structure  as  a  starting  point  for  design 
synthesis.  The  second,  traditionally  less  concerned  with  the  specification's  role  in  aiding  syn¬ 
thesis,  primarily  describes  module  behavior  or  function  with  a  view  toward  providing  a  frame  in  a 
formal  proof  of  design  correctness. 


Synthesis-directed  specification  approaches  begin  with  formal  descriptions  written  in  docu¬ 
mentation  languages  that  normally  capture  both  behavior  and  structure  of  the  intended  design. 
Many  of  these  languages  are  called  Computer  Hardware  Description  Languages  (CHDLs).  While 
interpreters  have  been  created  to  render  some  of  these  CHDLs  executable,  in  the  main  their  pur¬ 
pose  has  been  documentary,  and  their  role  in  the  specification  process  has  been  as  an  informal 
point  of  reference  during  design  elaboration. 

There  is  a  class  of  synthesis-directed  languages  in  which  the  role  of  capturing  a  starting 
point  for  synthesis  so  far  outweighs  the  specification  role  that  the  languages  are  rarely  referred  to 
as  CHDLs.  These  might  be  called  “generator  source  languages,”  because  their  role  is  analogous  to 
that  of  software  source  languages.  Descriptions  written  in  such  languages  (1)  usually  constitute 
an  intermediate  step  between  a  (perhaps  informal)  specification  and  lower-level  synthesized 
descriptions,  and  (2)  serve  as  input  to  generators  that  produce  executable  design  descriptions. 

Here  are  included  primarily  input  languages  for  automated  synthesis  aids,  such  as  chip  assemblers 
[Mudg81.  Katz83,  Katz84]  and  silicon  compilers  |Gray82,  Ance83,  Lipt83,  SST84]. 

Proof-directed  specification  approaches  have  undergone  a  change  of  direction.  They  began 
with  non-executable  specifications,  such  as  the  non-procedural  functional  language  used  by 
Wagner  in  1977  and  cited  by  Barrow  |Barr84];  such  specifications  were  reconciled  with  synthesized 
designs  using  manual  proof  techniques.  Lately,  however,  with  the  renewed  interest  in  artificial 
intelligence,  more  interest  has  been  shown  in  creating  proof-directed  specifications  that  can  be 
executed  by  inference  engines  to  prove  design  correctness  automatically;  thus  most  contemporary 
proof-directed  specifications  are  executable. 

A  natural  question,  raised  by  Cohen  at  the  1983  International  Coinerence  on  YTSI  [Cohe83], 
is  whether  a  single  interface  specification  technique  could  serve  both  synthesis  and  verification 
needs.  That  is,  can  a  single  technique  capture  sufficiently  the  behavior  and  structure  of  the 
desired  design  to  guide  the  synthesis  effort,  while  at  the  same  time  being  precise  enough  to  sup¬ 
port  formal  proof  of  design  correctness? 

£.3.8.1  Examplct. 

Since  Dallen  [Dall83j,  Dasgupta  (Dasg84),  and  Nash  [Nash84]  provide  excellent  surveys  of 
CHDLs,  it  suffices  to  note  here  that  CHDLs  can  be  grouped  into  three  classes,  the  block  languages 
(e.g.  PMS  [Siew82]),  the  register-transfer  (R-T)  languages  (e.g.,  CDL  (Chu74),  DDL  [Diet74, 


Maru85],  ISP  JSiew82),  ISPS  |Barb82]),  tod  the  graphical  languages  (e.g.,  Petri  nets  [Pete77j, 
Patois  (Dali83j,  Interface-Nets  |Moln85]). 


CHDLs  have  proliferated  furiously  [Wern84].  One  current  trend  is  toward  a  consensus 
CHDL;  an  international  group  has  been  working  for  more  than  ten  years  on  such  a  language, 
CONLAN  (Pilo85j.  Another  current  trend  seems  to  be  toward  extensible  omnibus  CHDLs  that 
can  be  used  to  describe  in  a  single  language  function,  structure,  and  layout  (e.g.,  the  VHSIC 
Hardware  Description  Language  (VHDL)  currently  under  development  by  Intermetrics  for  the  U.S. 
Department  of  Defense  |Dewe84,  Shah85]  and  GTE  Laboratories’  Zeus  [LiebSS] ).  Finally,  fine 
results  have  been  obtained  using  programming  languages  as  CHDLs,  such  as  the  use  by  Blaauw  of 
APL  for  this  purpose  [B!aa76,  Blaa83j. 

Barrow’s  VERIFY  system  [Barr84],  although  not  properly  a  member  of  this  section  because 
it  produces  executable  specifications,  typifies  the  state  of  the  art  in  proof-directed  specification 
approaches.  He  begins  with  a  set  of  primitive  modules,  represented  as  finite-state  machines  with 
known  black-box  function.  Next,  he  composes  these  modules  into  the  structure  of  the  target 
design.  Finally,  he  uses  a  PROLOG-based  interpreter  to  prove  that  the  mathematical  composi¬ 
tion  of  the  functions  making  up  the  interconnection  is  the  function  of  the  target  design. 

Can  a  single  specification  support  both  synthesis  and  verification?  Frankel  and  Smoliar 
[Fran79],  Rowson  [Rows80],  Gordon  [Gord81J,  Cardelli  and  Plotkin  [Card8l],  Hafer  and  Parker 
[Hafe83],  and  Sheeran  |Shee84]  have  all  suggested  the  feasibility  of  specifications  that  apply 
mathematical  compositional  systems  to  VLSI  design  components.  Subrahmanyam  [Subr83]  has 
recently  reported  on  the  development  of  a  theoretically  precise  specification  language  designed  to 
serve  as  input  to  a  silicon  compiler,  thereby  showing  a  fortiori  that  it  can  serve  to  guide  manual 
design  synthesis. 

S.S.S.S  Strengths/  Weaknesses. 

Formal  specification  methods  have  substantial  potential  for  dealing  with  the  complexity  lev¬ 
els  inherent  in  VLSI  design,  in  that  they  can  capitalize  on  their  foundations  in  discrete  mathemat¬ 
ics  and  the  theory  of  computation.  Nevertheless,  the  formalism  in  such  methods  is  now  largely 
foreign  to  programmers  and  managers,  even  to  those  with  engineering  backgrounds.  If  these 
methods  could  be  interpreted  in  automated  tools,  the  retraining  necessitated  by  their  introduction 
would  be  lessened,  although  certainly  not  eliminated.  Bui  methods  not  optimized  for  the  use  of 


such  took,  such  as  non-executable  formal  specifications  (which  now  usually  require  a  manual 
interface),  will  be  slow  to  be  accepted. 

On  the  other  hand,  methods  that  are  familiar,  such  as  clear-box  specification  using  CHDLs, 
will  be  abandoned  reluctantly,  and  the  use  of  such  techniques  is  currently  widespread  [Dasg84, 
Evan85],  CHDLs  for  black-box  specification,  whose  primitives  are  abstract,  do  not  have  the  same 
intuitive  appeal,  however.  Because  no  CHDL  has  emerged  as  a  standard  after  many  years 
[Wern84j,  a  needed  breakthrough  in  CHDL  technology  may  still  be  lacking. 

S.S.4  Mtthoit  for  Clear-Boz  Specification. 

Since  non-executable  specifications  were  addressed  in  the  preceding  section,  only  executable 
clear-box  specifications  will  be  covered  here. 

Clear-box  VLSI  specification  methods  are  an  evolution  of  specification  techniques  used  at 
lesser  degrees  of  integration.  The  primary  characteristic  of  such  clear-box  specifications  is  that 
they  prescribe  interfaces  by  inference,  rather  than  directly. 

i.S.f.l  Examples. 

Executable  clear-box  specifications  can  be  classified  according  to  the  level  of  abstraction  of 
the  primitives  appearing  in  the  clear  box.  The  executable  clear-box  CHDL  specifications  have  the 
highest-level  primitives,  such  as  registers.  Next,  generally  for  smaller  modules,  are  found  the  ubi¬ 
quitous  logic  diagrams  and  their  simulators.  These  are  especially  prevalent  in  the  composition  of 
systems  consisting  of  SSI  and  MSI  circuits.  Finally,  in  cases  in  which  a  replacement  for  an  exist¬ 
ing  module  is  being  developed,  circuit-  and  mask-level  simulators  are  available  to  enable  the  exist¬ 
ing  module  to  act  as  the  specification.  Each  technique  is  widely  used,  and  there  are  many 
languages  and  simulators  for  this  purpose. 

Excellent  results  have  been  reported  from  the  use  of  a  clear-box  specification  system  by  Dus- 
sault,  Liaw,  and  Tong  at  AT&T  Bell  Laboratories  [Murp83,  DussS4].  This  tool,  called  the  Func¬ 
tional  Design  System  (FDS),  enables  designers  to  construct  circuits  hierarchically  using  custom- 
designed  primitives  tailored  from  a  menu  of  options.  Designers  can  work  with  black-box  descrip¬ 
tions  of  each  primitive  written  in  a  special  executable  language.  FDS  is  currently  being  used  in  a 
production  environment. 


e.S.4  t  Strength)/  Weaknettet. 


Clear-box  specifications,  like  informal  specifications,  have  the  advantage  of  being  familiar  to 
designers.  They  also  provide  a  path  to  a  feasible  implementation,  whereas  black-box 
specifications  can  mask  fatal  implementation  difficulties  [Moln85],  From  a  VLSI  design  point  of 
view,  however,  clear-box  specifications  also  have  several  disadvantages,  as  section  1.3. 1.1  states. 
The  most  serious  is  that  they  confuse  architecture  (the  external  view)  with  implementation, 
elevating  low-level  concerns  too  early  in  the  design  process  to  achieve  good  design  partitioning 
and  unity.  Furthermore,  as  Parnas  notes  [Parn77a],  it  becomes  "very  hard  for  both  the  reader 
and  writer  of  specifications  to  distinguish  requirements  from  peculiarities  of  the  sample  implemen¬ 
tation."  ThuB  clear-box  specifications  may  constrain  the  implementation  unnecessarily. 

Zave  |Zave84j  lists  further  difficulties.  Clear-box  specifications  are  complex;  often  not  tak¬ 
ing  advantage  of  abstraction,  they  scale  up  poorly  and  are  hence  reduced  in  value  at  VLSI  levels 
of  integration.  Furthermore,  because  of  this  level  of  detail,  they  are  time-consuming  to  construct 
and  analyze.  Finally,  Dallen  [Dall83]  contends  that  clear-box  specifications  do  not  naturally  aid 
the  synthesis  process  in  hierarchical  design  because  they  are  usually  tied  to  fixed  levels  of  abstrac¬ 
tion. 


£.8.5  Methods  for  Formal,  Semantic,  Executable,  Black-Box  Specification. 

Because  critical  disadvantages  exist  with  each  method  of  VLSI  design  interface  specification 
discussed  thus  far,  examining  the  intersection  of  their  complements  provides  the  best  hope  for 
finding  techniques  meeting  the  five  requirements  of  section  2.2. 

Functional  specification  using  high-level  programming  languages  or  special-purpose 
specification  languages  is  the  primary  technique  that  appears  in  this  intersection.  Typically,  a 
black-box  interface  specification  is  constructed  for  the  module  under  design,  a  high-level  language 
is  used  to  describe  its  behavior,  and  the  simulated  output  is  compared  to  that  obtained  by  simu¬ 
lating  lower-level  representations  of  the  design.  Evaluation  of  the  specification  through  simula¬ 
tion,  rather  than  through  analysis  or  prototyping,  is  almost  always  used  because  of  the  intractable 
complexity  of  the  specification  at  VLSI  levels  of  integration.  Special-purpose  specification 
languages  have  arisen  because  programming  languages  can  be  cumbersome  to  use  for  this  purpose: 
they  do  not  handle  timing  in  a  natural  way,  and  it  is  difficult  to  make  specifications  written  in 
them  grow  with  the  design  life-cycle. 


t.S.5.1  Example  t . 

Many  designers  use  languages  such  as  APL,  Algol,  BLISS,  C,  and  Pascal  for  functional  simu¬ 
lation  of  system  specifications  (Dall83,  Evan85],  Lattin  et  al.  [Latt8lj  used  a  high-level  language, 
SIMULA,  directly  as  the  specification  medium  for  the  Intel  iAPX-432  chip.  That  is,  rather  than 
serving  as  a  simulator  for  a  separate  specification,  this  simulator  itself  filled  the  role  of  the  frame 
for  design  verification;  questions  were  resolved  by  “asking  the  machine.’’  Tham,  Willoner,  and 
Wimp  [Tham84]  of  Intel  updated  this  technique  in  their  recent  use  of  a  MAINSAIL  frame;  a  simi¬ 
lar  approach  was  also  used  by  the  designers  of  the  Hewlett-Packard  FOCUS  chip  |Cane83j.  The 
MetaLogir,  Inc.,  MetaSyr  silicon  compiler  [SiskS2]  accepts  as  input  a  LISP-like  executable 
description  of  the  function  to  be  implemented  (Wa.1184] .  Control  Data  Corporation’s  MIDAS  sys¬ 
tem  specifies  designs  using  a  programming  language  enhanced  with  timing  semantics  [Evan85|. 
Finally,  Suzuki  has  used  Concurrent  Prolog  to  specify  the  function  of  the  Dorado  computer 
[Suzu85j. 

Parker  and  Wallace  [Park8l]  identify  the  following  milestones  in  the  history  of  special- 
purpose  black-box  interface  specification  languages: 

—  Bell  and  Newell’s  port  semantics  (BeU71j; 

—  Curtis’s  Interface  Description  Language  {Curtis],  a  multi-level  extension  of  PMS  and  ISP 
developed  circa  1974-1975; 

—  Vissers’s  formal  description2  of  state  diagrams  using  APL  enhanced  with  timing  constructs 
[Viss76];  and 

—  Marino’s  proposed  MPLID  |Mari78],  a  language  for  specification  of  hierarchical  module  inter¬ 
faces. 

Parker  and  Wallace's  own  language,  SLIDE  (Structured  Language  for  Interface  Description  and 
Evaluation),  synthesizes  these  developments  into  an  executable  black-box  register-transfer 
language.  SLIDE’S  major  contributions  are  this  synthesis  of  trends  and  its  elegant  facility  for 
describing  module  interconnections  as  communicating  asynchronous  concurrent  processes. 


*  See  xljo  [Bl»»76] 
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Figure  2*5.  Bain’s  External  Outlines  [Bain84j. 

Several  other  interesting  approaches  have  recently  been  taken  to  the  development  of  execut¬ 
able  special-purpose  languages  for  black-box  VLSI  design  interface  specification.  For  example, 
Bain  |Bain84]  has  incorporated  into  his  CHECK-ME  design  methodology  verification  system  a 
technique,  based  on  Penfield’s  [Penf72]  “wiring  operators,”  which  completely  characterizes  a  cir¬ 
cuit  using  an  “external  outline”  consisting  of  a  list  of  terminal  names,  a  limited  set  of 
input/output  attributes,  an  electrical  drive  factor  based  on  the  shape  of  the  internal  transistors, 
and  a  broad  characterization  of  the  implementation  strategy  that  he  calk  “lineage”  (Figure  2-5). 
While  it  requires  extension  to  achieve  semantic  adequacy  at  greater  levek  of  specification 
refinement,  Bain's  method  is  encouraging,  for  it  illustrates  the  simplicity  that  can  be  achieved  in 
abstract  IC  circuit  interface  specifications  if  an  appropriate  set  of  abstractions  is  identified 

Tsai  and  Achugbue  [Tsai83]  provide  in  their  BURLAP  system  an  idea  of  what  a  timing-level 
extension  of  Bain’s  external  outline  might  look  like.  They  specify  the  abstract  interface  by  a 
"multi-cell  module”  (MCM)  description  consisting  of  the  components  listed  in  Figure  2-6.  Figure 
2-7  shows  the  contents  of  a  fy;  leal  BURLAP  specification. 

The  hierarchy  exploited  by  Bain  and  by  Tsai  and  Achugbue  has  been  formally  analyzed  by 
Chen  and  Mead  [Chen83j.  Using  mathematical  methods,  they  define  a  trmantic  hierarchy  of 
specification,  and  of  the  ensuing  verification  by  simulation,  similar  to  that  depicted  in  Figure  2-4. 
In  this  way,  they  formally  partition  the  design  process  and  suggest  that  a  uniform  representation 
can  be  used  to  provide  interface  descriptions  as  simulator  input  at  all  levels.  Individual  design 
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Figure  2-6.  Components  of  a  BURLAP  Interface  Specification 
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Figure  2-7.  A  BURLAP  Specification  of  a  Static  RAM 
[Tsai  83]. 


modules,  in  their  work,  are  conceived  as  separately-compilable  MAINSAIL  descriptions  of  finite- 
state  machines,  encapsulating  design  details  at  appropriate  levels  of  semantic  abstraction  To 


date,  however,  their  work  has  centered  on  creating  the  forma)  bases  necessary  to  prove  correct¬ 
ness,  rather  than  on  developing  an  abstract  interface  specification  technique  tractable  at  VLSI  lev¬ 
els  of  integration. 

Another  special-purpose  specification  language,  previously  cited,  that  makes  use  of 
separately-compilable  modules  that  represent  finite-state  machines  is  included  in  Barrow's  VER¬ 
IFY  system  [Barr84].  VERIFY  also  uses  the  hierarchical  approach  recommended  by  Chen  and 
Mead  to  predict  the  functional  behavior  of  an  interconnection  of  these  modules  from  a  description 
of  the  behavior  of  each.  But,  instead  of  using  the  simulation  customary  in  the  verification  pro¬ 
cess,  VERIFY  uses  a  PROLOG-based  interpreter  to  compare  the  predicted  behavior  with  a  set  of 
equations  that  specify  the  system’s  behavior.  To  date,  VERIFY  has  been  tested  on  functional 
specifications  only,  but  its  approach  to  verification  is  encouraging,  in  that  it  can  be  replicated 
hierarchically  to  scale  up  to  VLSI  design  levels  without  the  need  for  specifications  to  be  re- 
executed  at  each  level  of  refinement.  A  sample  VERIFY  specification  is  shown  in  Figure  2-8. 

The  inherent  complexity  of  VLSI-level  system  specifications  has  hindered  not  only 
verification  but  also  the  development  of  silicon  compilers,  the  hardware  design  counterpart  of  the 
transformational  implementation  of  operational  specifications  mentioned  by  Zave  [Zave84], 
Subrahmanyan)  |Subr83]  has  addressed  both  problems  simultaneously  in  his  specification  formal¬ 
ism  called  BehaviorExpressions,  an  algebraic  specification  language  designed  also  to  serve  as  input 
to  a  high-level  silicon  compiler.  Figure  2-9  gives  an  example  of  a  specification  expressed  in  this 
language. 

Subrahmanyam's  work  addresses  the  need  for  semantic  adequacy  at  each  of  the  functional, 
geometric,  and  electrical  levels  mentioned  earlier;  it  also  includes  paradigms  for  instructing  the 
silicon  compiler  to  consider  performance  and  co6t  data  in  performing  its  transformations.  His 
research  plan  is  comprehensive  and  ambitious,  and  its  results  could  prove  significant  indeed. 

S.S.5.S  Strengths/  Weaknesses. 

Functional  interface  specification  with  abstract  high-level  languages  has  acb’eved  the  most 
promising  results  of  any  technique  discussed  Specification  refinement,  however,  requires  the 
eventual  representation  of  dense  semantics  (particularly  geometric  and  electrical  information,  con¬ 
currency,  and  parallelism).  Although  it  is  possible  to  express  such  semantics  and  their  complex 
dat3  types  in  conventional  programming  languages,  not  many  designers  are  now  familiar  with  the 
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StackChip(s)  = 

INITIALIZE.  StackChip  (NEWSTACK) 

+ 

INSERT  x.  StackChip  (PUSH(s,x)) 

+ 

DELETE  TOP(s).  StackChip  (POP(s)); 

where  Stack  is  an  abstract  data  type  with  predefined  syntax  and  semantics;  INITIALIZE, 

INSERT,  and  DELETE  are  global  ports  (two  input  and  one  output,  respectively);  s  is  a  parameter 
that  represents  an  instance  of  the  type  Stack;  and  NEWSTACK,  PUSH,  and  POP  are  operations 
defined  for  the  type  Stack. 

Figure  3-9.  Specification  Using  BehaviorExpressions 
[Subr83], 


disciplined  programming  style  that  such  expression  requires.  Consequently,  these  languages  are 
now  more  frequently  used  for  functional  specification  alone. 

Special-purpose  languages  possess  more  powerful  primitives  for  expressing  design  semantics, 
but  their  degrees  of  perceived  cost-effectiveness  and  malleability  vary,  particularly  in  the 
representation  of  very-large-scale  designs.  And,  as  Evanczuk  notes,  a  special-purpose  language 
has  a  smaller  user  community;  he  believes  that  the  user  momentum,  availability,  and  portability 
of  general-purpose  programming  languages  makes  techniques  based  on  them  more  likely  to 
succeed  (Evan85j. 
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£.4  Parnas’s  Techniques  for  Abstract  Interface  Specification. 

Parnas’s  approach  to  attacking  the  complexity  issues  of  the  “software  crisis”  has  been  one 
of  “divide  and  conquer.”  Few  others  have  elucidated  as  well  as  he  the  issues  involved  in  dividing 
the  software  design  task.  A  brief  review  of  his  treatment  of  these  issues  is  in  order. 

£.41  State  Machines. 

In  an  early  paper  (Parn72aj,  Parnas  set  out  the  module  as  his  software  building  block  and 
described  how  it  was  to  be  specified.  His  was  a  black-box  specification,  and  his  model  of  ihe 
black-box  contents  a  state  machine.  His  choice  of  this  forma)  but  familiar  model  is  typical  of  his 
philosophy:  understanding  is  the  goal,  and  understanding  is  aided  by  simplification,  without 
compromising  precision,  wherever  possible. 

Interaction  with  Parnas’s  module  takes  place  entirely  through  what  be  later  called  access 
functions  (or  access  programs).  These  functions  make  up  a  major  part  of  a  module's  specification 
and  can  be  invoked  by  other  modules  either:  (1)  ( effect  access  function)  to  change  the  state  of  the 
module  by  providing  an  input  value;  or  (2)  (value  access  function)  to  read  out  the  state  of  the 
module.  By  restricting  access  functions  to  one  of  these  two  types,  the  opportunity  for  prescrip¬ 
tion  of  an  intended  implementation  (which  would  cause  the  specification  to  become  clcar-box)  is 
reduced  |Bart77]. 

£.4-£  Traces. 

Parnas  believed  strongly  [Parn72a]  that  specifications  should  be  minimized,  in  the  sense  that 
only  the  information  required  for  the  specification  should  be  provided  "and  nothing  more.”  He 
felt  that  a  chief  source  of  specification  failure  was  overprescription  or  redundancy,  a  view  that 
was  then  controversial  but  that  has  now  been  generally  accepted  [MeyeSSj.  With  Bartussek 
[Bart77],  Parnas  became  concerned  that  functions  in  the  specification  could  potentially  prescribe 
an  implementation.  To  be  sure,  the  definitions  of  such  functions  were,  by  fiat,  unavailable  out¬ 
side  the  module  being  specified  (leading  to  their  being  called  “hidden  functions”  in  the  literature). 
But  their  existence  bothered  Bartussek  and  Parnas,  especially  because  of  the  suggestion  (see  sec¬ 
tion  2.1.3)  that  modules  could  be  specified  “by  giving  a  program  whose  behavior  would  be  accept¬ 
able  and  asking  that  the  program  produced  be  'equivalent'.”  Such  "equivalent  functions,"  they 
felt,  provided  superfluous  information  (Parn75a). 


Syntax: 


PUSH:  <integer>  X  <stack>  -*  <stack> 

POP:  <stack>  —►  <stack> 

TOP:  <stack>  -♦  <integer> 

DEPTH:  < stack  >  -  <  integer  > 

Semantics: 

A.  Legality: 

(1)  &(T)  =>  &(T.PUSH(a)) 

(2)  &(T.TOP)  =  &(T.POP) 

B.  Equivalence: 

(3)  T.DEPTH  =  T 

(4)  T.PUSH(a).POP  =  T 

(5)  &(T.TOP)  =>  T.TOP  ==  T 

C.  Values: 

(6)  &(T)  =>  V(T.PUSH(a).TOP)  =  a 

(7)  &(T)  =>  V(T.PUSH(a).DEPTH)  =*  1  +  V(T.DEPTH) 

(8)  V(DEPTH)  =  0 


Figure  2-10.  Specification  Using  Traces  of 
a  Stack  for  Integer  Values  [Bart77]. 


Notation: 

Dot  (.)  is  the  functional  composition  operator. 

&(T)  is  TRUE  if  calling  the  functions  in  the  sequence  specified  in  the  trace  with  the 
arguments  given  in  the  trace  when  the  module  is  in  its  initial  state  will  not  result  in  an  abnormal 
exit. 

V(T)  is  a  value  access  function  that  retiirns  information  about  the  module  state. 


The  result  of  Bartussek’s  and  Parnas's  work  was  an  “axiomatic"  specification  approach 
called  "traces.”  It  is  called  axiomatic  [Lisk79j  because  a  specification  using  traces  makes  state¬ 
ments  (axioms)  only  about  the  effects  of  function  calls;  it  contains  no  reference  to  any  internal 
data  structure.  Figure  2-10  gives  an  example  of  such  a  specification.  Specifications  using  the 
trace  approach  are  termed  complete  (i.e.,  they  completely  determine  externally  visible  module 
behavior)  if  one  can  determine  from  the  specification  the  value  returned  by  every  trace  (sequence 
of  function  calls)  ending  with  a  value  access  function  and  not  causing  an  abnormal  exit.  The  use 
of  traces  for  IC  specification  has  been  reported  by  Rem,  van  de  Snepscheut,  and  Udding  [Rem83]. 

8.4  S  The  Software  Cott  Reduction  (SCR)  Project. 

Parnas,  sensitive  to  the  frequently-made  criticism  (see  section  1.3. 1.2)  that  claims  made  for 
new  software  engineering  methods  are  usually  poorly  supported,  undertook  a  major  project  begin' 
ning  in  the  late  1970's  to  test  his  and  other  software  engineering  principles  in  a  real-world 


environment.  This  project,  sponsored  by  the  Office  of  Naval  Research,  is  structured  around  the 
re-engineering  of  obsolete  avionics  software  for  the  Navy  A-7  aircraft.  Thus  it  provides  a  point  of 
comparison  for  the  efficacy  of  the  new  software  engineering  methods. 


Fn_name 

Parm_type 

Parm_info 

Undesired_evente 

+EQ+ 

pl:real;I 

!!  sou  reel! 

%%constant  dest’n%% 

+NEQ+ 

p2:real;I 

!!  source!! 

+GT+ 

p3:boolean;0 

l+destination-f! 

+GEQ+ 

+LT+ 

+LEQ+ 

p4:real;l 

!!user  threshold!! 

+ADD+ 

pl:real;I 

!!source!! 

%%constant  dest’n%% 

+MUL+ 

p2:real;I 

!!source!! 

%range  exceeded^ 

+SUB+ 

p3:real;0 

!+destination+! 

(...) 

Program  Effects 

+ADD+ 

p3  =  pi  +  p2 

+EQ+ 

p3  =  (pl  =*  p2) 

+GEQ+ 

p3  =  (pl  =•  p2) 
OR  (pl  -  p2 

(...) 

is  positive) 

*  (This 

equality  is  precisely  defined  in 

a  text  footnote) 

Figure  2-11.  An  Access  Program  Table 
for  Specifying  Operations  on  Real  Entities  [Clem84], 


Notation: 

+  nome+  indicates  that  name  is  an  access  function. 

!!namt!!  indicates  that  name  is  a  term  defined  elsewhere  in  the  specification. 

!  +  nome+!  indicates  (here)  that  name  is  a  value  produced  by  an  access  function. 

%name%  indicates  that  name  is  an  undesired  event  that  may  not  be  detected  until  run¬ 
time.  Double  percent  signs  indicate  an  undesired  event  that  will  be  detected  at  system 
generation-time. 

Except  for  access  functions,  each  name  is  defined  in  a  dictionary  contained  elsewhere  in  the 
specification. 


One  product  of  the  SCR  Project  has  been  an  abstract  interface  specification  method 
(Parn77bj  that  evolves  traces  (in  recognition  of  their  frequently 'Unworkable  complexity)  by  relax¬ 
ing  the  restriction  against  equivalent  functions.  The  SCR  specification  [Heni78,  Brit81a]  consists 
of  two  partially  redundant  interface  descriptions: 

—  An  assumption  lift,  an  English-language  statement  of  assumptions  implicit  in  the  functional 
specifications.  It  contains  both  basic  assumptions  underlying  module  construction  and 
assumptions  about  “undesired  events"  (what  is  to  occur  in  each  foreseen  incorrect  or  error 
situation).  The  assumption  list  makes  it  easier  to  identify  invalid  assumptions  and  is  reviewed 
by  both  programmers  and  non-programmers. 

—  Formal  functional  specification t  of  programming  constructs  embodying  the  assumptions. 

These  can  be  used  directly  in  user  programs.  They,  in  turn,  consist  of  access  functions  and 
events,  i.e.,  signals  from  a  module  to  other  modules  indicating  the  occurrence  of  some  state 
change  within  the  first  module.  Events  are  “reported  via  access  programs  that  do  not  return 
until  the  specified  conditions  hold"  [Clem84].  Access  functions  syntax  and  semantics  are 
presented  in  an  access  program  table  (Figure  2-11). 

The  assumption  list,  access  program  table,  and  the  dictionaries  defining  the  terms  and  data  types 
used  in  each  are  therefore  the  primary  components  of  an  SCR  specification. 

The  SCR  specification  method  has  also  been  employed  in  other  projects  (see,  e.g.,  [Hest8l]) 
and  has  been  the  subject  of  several  years  of  both  theoretical  and  practical  research.  Its  chief 
benefits  have  been  found  to  be  the  facilitation  of  a  structuring  set  of  system  documentation  and 
the  ready  implementation  of  information  hiding  [Brit83|. 

£.5  Summary. 

Parnas's  techniques  for  abstract  interface  specification  have  considerable  potential  for  exten¬ 
sion  to  the  VLSI  design  domain.  Like  the  other  techniques  discussed  in  section  2.3.5,  they  possess 
the  desirable  characteristics  of  being  formal,  semantic,  executable,  and  black-box.  But  their  chief 
merit  lies  in  their  unusual  capability  for  implementing  a  precise  separation  of  concerns  (informa¬ 
tion  hiding),  not  only  among  modules  but  also  vertically  along  the  hierarchy  of  specification 
refinement  depicted  in  Figure  2-4.  This  precision,  coupled  with  Parnas's  concern  for  6paxeness, 
suggests  that  these  techniques  can  serve  as  a  starting  point  in  the  development  of  an  abstract 
interface  specification  method  for  VLSI  designs  that  meets  the  five  criteria  of  section  2.2. 
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CHAPTER  3 

AN  ABSTRACT  INTERFACE  SPECIFICATION  APPROACH 
FOR  VLSI  DESIGNS 

In  the  preceding  chapter,  I  have  examined  related  contemporary  work  in  the  specification  of 
abstract  interfaces  for  VLSI  designs  and  have  pointed  out  the  shortcomings  of  existing  VLSI 
design  interface  specification  methods.  This  chapter  reports  on  a  new  approach  to  such 
specification  that  addresses  some  of  these  shortcomings,  presenting  the  approach  by  describing  a 
method  that  uses  it.  Chapter  4  contains  an  evaluation  of  the  method's  utility  and  effectiveness, 
and  chapter  5  provides  conclusions  and  suggestions  for  future  research. 

Chapter  3  is  organized  as  follows.  I  begin  by  describing  an  IC  module  abstract  interface 
specification  method,  an  extension  of  Parnas’s  interface  specification  techniques  to  the  domain  of 
VLSI  design.  The  second  section  provides  a  detailed  example  of  how  the  new  method  can  be  used 
to  specify  the  interface  of  an  IC  module.  Next,  I  show  how  the  behavior  of  compositions  of  such 
specifications  can  be  predicted  using  Communicating  Sequential  Processes  [Hoar78].  A  final  sec¬ 
tion  focuses  on  simplifications  to  the  method  that  can  be  obtained  by  exploiting  certain  charac¬ 
teristics  of  the  VLSI  design  process. 

S.l  Overview  and  Description  of  the  Approach. 

As  has  been  seen,  a  critical  purpose  of  a  VLSI  design  interface  specification  is  to  serve  as  a 
frame  for  subsequent  design  verification.  In  attempting  to  develop  a  specification  method  that 
fulfills  this  purpose,  however,  one  encounters  contradictory  constraints.  On  the  one  hand,  it  is 
desirable  to  construct  the  specification  early  in  the  design  process,  to  capture  high-level  design 
concerns  and  to  guide  subsequent  design.  However,  in  practice  even  the  most  top-down  design 
turns  up  subtle  contradictions  among  the  constraints,  requiring  backtracking.  What  is  needed, 
and  what  I  propose,  is  an  interface  specification  approach  that  can  start  by  capturing  high-level 
concerns  but  then  can  be  refined  into  a  more  particular  specification  as  further  information 
becomes  available  over  the  course  of  the  design.  Such  a  specification  fulfills  the  objectives  (sec¬ 
tion  2.2)  of  adequacy  and  malleability;  it  can  serve  as  a  verification  frame  throughout  the  design 
life-cycle,  because  it  can  “grow"  with  the  design. 


Another  objective  addressed  in  this  research  has  been  the  perceived  cost-effectiveness  of 
interface  specification  at  VLSI  complexity  levels.  As  has  been  stated,  dear-box  specification 
methods  do  not  scale  well  to  VLSI  levels  because  their  complexity  must  increase  directly  with  the 
number  of  components  in  the  circuit.  Several  black-box  techniques  have  been  proposed,  but  few 
include  abstraction  mechanisms  that  effectively  reduce  complexity  by  crisp  partitioning  of  con¬ 
cerns.  In  the  approach  I  propose,  precise  partitioning  of  design  function  is  achievable,  and  com¬ 
plexity  can  be  further  reduced  by  partitioning  timing  from  function.  Additionally,  the  proposed 
partitioning  mechanisms  can  be  used  for  geometric  as  well  as  for  functional/electrical  information, 
enhancing  the  approach's  spareness  and  cost-effectiveness. 

Finally,  the  proposed  approach  includes  techniques  that  support  the  objective  of  change 
management  by  precisely  quantifying  the  concept  of  specification  adherence.  Such  techniques 
permit  design  maintainers  to  measure  the  degree  to  which  a  candidate  replacement  module  meets 
its  specification  and  thus  to  predict  how  much  change,  if  any,  will  be  introduced  beyond  the 
module  boundary  by  its  inclusion  in  the  design.  If  such  techniques  exist,  they  have  not  before 
been  applied  to  change  management  in  VLSI  design. 

The  following  paragraphs  provide  an  overview  of  the  proposed  approach.  In  general,  this 
approach  extends  Pamas's  abstract  interface  specification  techniques  for  software,  providing 
specification  refinement  and  complexity  management  in  a  hierarchy  of  virtual  machines.  A 
specification  language  is  not  part  of  the  proposal,  and  the  notation  and  syntactic  constructs  pro¬ 
vided  are  not  purported  to  be  superior.  Instead,  effort  has  been  focused  on  identifying  and  study¬ 
ing  the  issues  involved  in  specifying  abstract  interfaces  for  VLSI  designs.  The  proposed  approach, 
therefore,  is  ai.  attempt  to  address  these  issues  generically,  and  the  techniques  proposed  herein 
represent  a  class  of  abstract  interface  specification  methods. 

S.1.1  Model. 

The  proposed  abstract  interface  specification  model  is  a  simple  “black  box,"  consisting  of  an 
abstract  model  of  a  elate  (Figure  3-1).  The  state  consists  of  a  finite  set  of  entities  called  etate 
variables  and  is  accessed  through  a  distinguished  subset  of  those  variables  called  pins;  state  vari¬ 
ables  that  are  not  pins  are  called  internal.  Data  enter  and  leave  the  module,  via  the  pins,  in  sig¬ 
n'll  variables.  This  model  corresponds,  of  course,  to  the  state  machine  model  used  by  Parnas 
|Parn72a],  Bartussek  [Bart77],  Barrow  {Barr84j,  and  others  [Lisk75]  in  the  treatment  of  abstract 
data  types  in  software,  where  by  "abstract  data  type"  is  meant  a  set  of  objects  together  with  a 


Figure  3-1.  Basie  Specification  Model. 

(Pi  =  Pin  i,  i  =  1 . 7) 

set  of  operations  on  those  objects. 

8.1.2  Data  Typing. 

Indeed,  each  pin  and  internal  state  variable  in  the  model  depicted  in  Figure  3-1  is  a  particu¬ 
lar  instance  of  a  single  generic  abstract  data  type,  called  here  the  generic  elate  type.  The  objects 
in  the  generic  state  type  are  signals;  the  operations  on  the  signals  vary,  but  typically  include 
transmission,  inversion,  selection,  and  so  on.  The  generic  state  type  is  generic  because  its  particu¬ 
larizations  depend  on  the  specification  of  values  for  semantic  and  syntactic  attributes,  which  are 
parameters  used  in  the  definition  of  type  operations  (semantic  attributes)  and  in  the  definition  of 
legal  type  usage  from  outside  the  module  (syntactic  attributes).  Pins  and  internal  state  differ, 
therefore,  in  that  internal  state  variables  possess  no  syntactic  attributes;  this  is  their  only 
difference. 

Since  the  pins  and  internal  module  state  are  the  only  objects  in  this  model,  it  is  in  the 
definition  of  the  generic  state  type  that  the  level  of  the  specification  is  determined.  A 
specification  whose  generic  state  type  has  simpler  syntax  or  semantics  (such  as,  for  example, 
“signal-type  =  Boolean”)  is  a  high-level  specification,  whereas  a  specification  whose  generic  state 
type  has  more  complex  syntax  or  semantics  (such  as  "signal-type  =  vector,"  where  the  vector 
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consists  of  a  Boolean  functional  value  plus  validity  and  signal  strength  values)  is  a  lower-level 
specification.  The  dilemma  of  contradictory  constraints  (alluded  to  earlier)  here  confronts  those 
who  would  construct  specification  methods.  What  kinds  of  syntax  and  semantics  should  be 
included  in  the  generic  state  type?  With  too  much  detail,  the  specification  cannot  be  constructed 
until  after  it  is  needed  in  the  design  process;  with  too  little,  the  specification  becomes  rapidly 
overtaken  by  emerging  information  gathered  from  lower-level  design. 

S.l.S.l  Data  Type  Evolution. 

The  answer,  I  believe,  is  not  to  limit  an  interface  specification  to  any  one  level  of  data  typ¬ 
ing,  but  instead  to  evolve  the  specification  generic  state  type  to  increasing  levels  of  detail  over  the 
course  of  the  design.  In  this  interpretation,  a  pin  or  internal  state  variable  is  assigned  a  high-level 
type  early  in  the  specification  process  and  then,  as  the  design  process  continues,  the  generic  state 
type  is  made  more  complex  so  that  specification  syntax  and  semantics  are  strengthened  in  a 
natural  and  necessary  way.  I  call  this  evolution  of  specifications  by  data  type  particularization 
specification  refinement  (see  section  2.2.2,  especially  Figure  2-4). 

Let  us  illustrate  specification  refinement  by  continuation  of  the  earlier  example.  Early  in 
the  specification  process  a  signal  might  be  assigned  the  type  “Boolean,”  a  type  that  is  clearly  a 
high-level  abstraction  of  the  functional  and  electrical  characteristics  of  its  signal.  Later,  without 
sacrificing  the  earlier  characterization,  the  Boolean  type  for  this  signal  might  be  extended  into  a 
type  that  consists  of  four  bits  of  information.  One  of  these  is  the  earlier  Boolean  type,  but  a 
second  bit  might  describe  the  first  bit’s  validity  (i.e.,  "11”  might  be  a  valid  “one,”  whereas  “10” 
might  represent  an  indeterminate  state)  and  the  remaining  two  bits  might  describe  the  strength  of 
the  signal  described  by  the  6rst  two. 

It  is  important  (indeed  essential)  to  this  development  that  the  particularization  of  these  data 
types  represent  an  evolution  (and  not  a  revolution).  Frequently,  when  high-level  specifications  are 
found  to  be  lacking  in  essential  semantic  information,  they  are  discarded  and  a  new  specification 
is  developed.  However,  this  poses  the  problem  of  reconciling  the  new  specification  with  the  old 
one,  a  manual  (hence  error-prone)  process  at  best.  It  is  much  better  to  evolve  the  higher-level 
specification  into  the  lower-level  one  and  thus  to  avoid  the  reconciliation  problem.  As  has  been 
stated  earlier,  such  an  evolutionary  specification  is  integrated  into  the  design  life-cycle.  This 
benefit  becomes  even  more  apparent  when  it  is  noted  that  an  evolutionary  approach  makes  it  pos¬ 
sible  to  compose  modules  at  a  high  level  of  specification  with  modules  at  a  lower  level  and  still 
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have  the  composition  be  meaningful.  Such  mixed-level  specification  can  aid  significantly  in  an 
incremental  design  or  redesign  effort. 

The  concept  of  evolution  is  made  more  precise  in  the  following 

Definition.1  Let  <A,  OA>  and  <B,  OB>  be  data  types,  in  which  the  first  component  of  the 
ordered  pair  is  a  set  of  objects  and  the  second  is  a  set  of  operations  on  those  objects.  Then 
<B,  OB>  is  an  evolutionary  particularization  (or  evolutionary  refinement)  of  <A,  OA>  iff  there 
are  two  mappinp  4>:  A-*B  and  i>:  OA-+OB  such  that  for  all  o  t  OA  and  for  all  a  t  A 

This  definition  is  illustrated  in  Figure  3-2. 

A  familiar  example  of  an  evolutionary  refinement  is  the  commonly-understood  refinement  of 
the  data  type  “integer"  into  the  data  type  "real."  Real  operations  on  integers  do  not  give  results 
inconsistent  with  those  of  counterpart  integer  operations  on  integers. 

S.l.S.S  Data  Type  Dimensionality. 

Whereas  software  interfaces  are  usually  characterized  in  the  single  dimension  of  function,  IC 
interfaces  traditionally  are  recognized  to  contain  information  in  three  dimensions:  the  functional, 
geometrical,  and  electrical.  These  axes  do  not  seem  to  be  orthogonal;  instead,  an  1C  module’s 
electrical  information  can  be  considered  a  refinement  of  its  functional  information,  and  so  the 
functional  and  electrical  axes  can  be  collapsed  together.  Therefore,  pins  and  state  variables  could 

Data  Type 

<B,  OB>:  ^o)  -»  =  ^(°(a)) 

!  I 

<A,  OA>:  o  -*  o(o) 

Figure  3-2.  Evolutionary  Data  Type  Refinement. 


be  characterized  by  data  types  with  functional/electrical  and  geometric  components. 

However,  this  traditional  characterization  leads  to  unnecessary  complexity;  an  alternate 
characterization  reduces  complexity  by  allowing  more  precise  partitioning  of  concerns.  Recall 
that  dynamic  verification  is  required  only  for  module  semantics  and  that  static  checking  suffices 
for  module  syntax.  It  happens  that  much  of  the  geometric  information  in  a  design  can  be 
classified  as  syntactic,  and  much  of  the  functional  /electrical  information  is  semantic.  (This 
correspondence  is  not  complete:  designs  possess  semantic  geometric  information  (e.g.,  current  den* 
sity)  and  syntactic  functional/electrical  information  (e.g.,  whether  a  signal  is  used  for  input  or 
output)).  But,  recognizing  that  the  purpose  of  a  specification  is  to  aid  in  verification,  it  is  more 
efficient  to  partition  specification  elements  along  syntactic  and  semantic  axes  than  along 
functional/electrical  and  geometric  axes.  Consequently,  in  this  method  generic  state  types  exist 
at  discrete  levels  of  semantic  and  syntactic  complexity,  and  the  particular  specification  state  type, 
hence  the  level  of  the  specification,  is  fixed  by  a  pair 

<semantic_Jevel,  syntactic_level>. 

Here  are  some  well-known  examples  of  semantic  and  syntactic  levels: 

a.  Semantic.  At  lesser  levels  of  specification  refinement,  generic  state  types  have  semantics  on  the 
functional  end  of  the  functional/eiectrical  spectrum.  Functional/electrical  values  here  are  ty,> 
ically  drawn  from  a  finite  set,  of  size  two  (Boolean  signal  levels),  three  (Boolean  with  the 
indeterminate  signal  level  often  characterized  as  “X,"  or  more  (e.g.,  twelve,  obtained  by  multi¬ 
plying  three  with  a  set  of  four  signal  strength  values,  such  as  floating  strength,  gate-driven 
strength,  steered  strength,  and  unknown  strength).  Note  that  the  three-value  type  is  an  evolu¬ 
tionary  refinement  of  the  two-value  type,  and  the  twelve  an  evolutionary  refinement  of  both. 

Further  on,  one  typically  requires  generic  state  types  with  performance  semantics,  containing 
signal  types  consisting  of  vectors  of  values  that  specify  signals  in  terms  f  rst  of  voltage  levels 
and  then  of  capacitive  and  resistive  drive,  current  leveb,  power  density  and  consumption,  and 


so  on. 


b.  Syntactic.  Here,  in  evolutionary  order,  are  three  sample  syntactic  types  that  might  be  used  in 
pin  specification: 

i.  An  “unspecified”  syntactic  type  that  imposes  no  constraint  whatsoever  on  pin  placement 

along  the  module  periphery. 

ii.  An  “order-specified”  syntactic  type  that  constrains  a  pin  to  a  given  position  in  an  order¬ 
ing  of  the  pin  set  around  the  periphery  of  the  module. 

iii.  A  “location-specified"  syntactic  type  that  constrains  a  pin  to  a  given  geometric  window 
on  the  boundary  of  the  module. 

8.1.8  Access  Functions  and  Specification  Refinement. 

Once  again  extending  the  techniques  of  Parnas  (section  2.4),  I  characterize  each  module  pin 
by  associating  with  it  an  access  function.  Such  access  functions  can  be  of  one  of  two  types:  value 
or  effect  [Clem84|.  Value  access  functions  are  used  to  obtain  a  value  on  a  pin;  effect  access  func¬ 
tions  are  used  to  set  internal  state  of  the  module  using  the  value  on  a  pin.  I  contend  that  VLSI 
modules  can  be  fully  specified  using  such  access  functions,  and  that  such  a  specification  permits 
efficient  change  management  over  the  course  of  the  VLSI  design  process. 

The  following  definitions  formalize  those  of  section  2.4  and  extend  them  into  the  IC  design 
domain: 

Definitions.  Let  an  1C  module  have  a  set  S  of  internal  states,  and  let  R  be  a  set  of  input  or  out¬ 
put  signal  values.  Then  a  value  access  function  is  a  function 

v:  S  -  R, 

and  an  effect  access  function  is  a  function 

w:  S  X  R  -*  S. 

From  these  definitions,  the  notion  of  (semantic)  specification  refinement  can  now  be  formal¬ 
ized.  (A  similar  formalism  can  be  drawn  for  syntactic  refinement.)  Let  V  and  W  be  the  sets  of 
value  and  effect  access  functions  associated  with  the  pins  of  a  given  module.  Let  us  first  identify, 
for  each  (value  access)  function  vt  in  V,  a  corresponding  signal  range  r, ,  such  that 

v, :  S  -»  r, ,  i  =  1,  2,  ....  card(V). 

Similarly,  for  each  (effect  access)  function  w(  in  W,  let  us  identify  a  corresponding  signal  domain 
d,  ,  such  that 

w( :  S  X  d,  -*  S,  i  =  1,  2 . card(W). 
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These  signal  range  and  domain  sets  encompass  the  spectra  of  values  that  pin  signals  can  attain. 

Observe,  therefore,  that  the  locus  of  specification  refinement  is  in  the  signal  range  and 
domain  sets  r,  and  d}  and  in  the  state  set  S.  By  our  previous  discussion  of  state  variable  seman¬ 
tics,  for  a  given  i  each  element  of  r, ,  d, ,  or  S  may  be  seen  to  be  a  vector  in  SE,  where  SE  is  a  set 
of  semantic  values.  Then  (semantic)  specification  refinement  is  the  redefinition  (by  enlargement) 
of  the  sets  r, ,  d  ,  and/or  S,  for  any  of  the  access  functions,  and/or  for  the  state  set,  which  make 
up  the  specification. 

An  example  may  help.  Suppose,  for  pin  1  in  a  given  module,  SEj  =  {0,1}.  This  description 
corresponds  to  pure  behavioral  simulation  using  two-valued  logic.  If  one  wished  to  refine  the 
specification  to  three-valued  logic,  he  would  represent  this  refinement  as  a  redefinition  of  SEj  to 
{0,1, X}. 

As  another  example,  a  module's  internal  state  might  consist  of  vectors  in 
{strong  0,  strong  1,  weak  0,  weak  1}. 

A  specification  refinement  might  redefine  this  set  to 

{floating,  unknown,  6teered  0,  steered  1,  gate-driven  0,  gate-driven  1}. 

S.I.  '  Scheduling. 

How  should  scheduling  be  handled  by  this  specification  method?  This  important  question 
can  b«  addressed  in  at  least  two  ways.  A  first  way  is  to  add  a  separate  temporal  dimension  to  the 
generic  state  type  semantics,  so  that  pins  and  internal  st3te  variables  could  have  scheduling 
semantics  in  addition  to  functional/electrical  (and  possibly  geometric)  semantics.  This  could  lead, 
for  example,  to  a  state  type  data  structure  consisting  of  a  Boolean  signal  level,  a  signal  strength, 
and  a  clock  phase  during  which  the  signal  is  active.  Bear  in  mind,  however,  that  we  have  been 
seeking  to  control  specification  complexity  by  precisely  separating  concerns.  Adding  a  temporal 
dimension  to  data  type  semantics  detracts  from  this  complexity  control  objective  by  mixing  two 
potentially  separable  kinds  of  information,  i.e.  functional/electrical  and  scheduling  semantics. 
Indeed,  from  the  viewpoint  of  local  (module)  functional/electrical  concerns,  clocked  signals  are 
not  semantically  different  from  unclocked  signals:  scheduling  information,  if  any,  is  external  (glo¬ 
bal).  Including  global  information  in  a  module  interface  specification  violates  information  hiding 
by  including  knowledge  of  the  module's  context. 


A  different,  albeit  less  conventional,  way  to  handle  scheduling  is  to  treat  scheduled  signals 
semantically  the  same  as  unscheduled  signals  and  to  add  scheduling  information  instead  to  the 
syntactic  portion  of  the  specification.  Because  clock  signals,  for  example,  change  the  state  of  a 
module  just  as  other  signals  do,  one  can  define  access  functions  corresponding  to  clock  inputs  and 
outputs  just  as  for  other  pins.  Scheduling  itself  then  becomes  a  global  concern  and,  as  such,  is 
dealt  with  syntactically  at  the  system  integration  level.  This  method  of  treating  scheduling 
achieves  separation  of  concerns  and  is  a  substantial  conceptual  simplification.  As  will  be  shown  in 
section  3.3,  the  synchronization  and  scheduling  of  individual  access  functions  within  a  module  can 
be  partitioned  from  the  description  of  access  function  semantics,  which  can  in  turn  then  be  cast  as 
independent  (asynchronous)  sequential  processes. 

S.  1.5  Specification  Adherence  and  Tolerance. 

What  does  it  mean  to  say  that  a  module  adheres  to  such  a  specification?  The  association  of 
module  semantics  with  access  functions  enables  us  to  relate  the  concept  of  adherence  to  access 
function  terminology. 

I  will  formalize  the  concept  of  adherence  by  appealing  to  the  fuzzy  set  theory  pioneered  by 
L.A.  Zadeb  je.g.,  Zade75,  Zade84j.  Fuzzy  sets  are  sets  for  which  set  membership  is  not  defined 
solely  by  an  in-or-out  criterion.  Instead,  Zadeh  defines  a  fuzzy  set  membership  function 

p{Fj  :  A  -  [0,1], 

that  indicates,  for  each  element  of  a  set  A,  its  grade  or  degree  of  membership  in  a  fuzzy  set  F. 
Often,  when  A  is  a  continuous  interval,  p[F]  is  a  monotone  function  over  A  (Figure  3-3). 

In  software  design,  in  which  functional  adherence  is  the  only  real  concern  (section  2.2.2), 
adherence  can  be  defined  with  traditional  set  theory.  That  is,  for  a  given  module  specification, 
there  will  be  a  set  of  modules  that  adhere  to  the  specification,  and  a  complementary  set  of 
modules  that  do  not.  But  in  hardware  design,  adherence  is  not  so  sharply  characterized,  for  the 
reason  noted  in  section  2.1:  “Circuits  must  not  only  work,  they  must  perform."  There  must  be  a 
continuum  of  the  utility  of  specification  adherence  that  corresponds  to  the  continuum  of  perfor¬ 
mance.  Consequently,  the  set  of  modules  that  adhere  to  a  specification  is  a  fuzzy  set.  1  will 
further  introduce  for  each  specification  adherence  functions,  analogous  to  membership  functions, 
which  map  modules  onto  the  interval  (0,1]  according  to  the  utility  of  the  degree  to  which  they 
satisfy  the  specification. 


Figure  3-3.  A  Funj  Set  F 
and  its  Membership  Function  ^[FJ  [Zade84j. 


Unlike  fuzzy  sets,  however,  which  possess  a  single  membership  function,  an  IC  interface 
specification  must  have  multiple  adherence  functions,  one  for  each  of  the  multiple  points  at  which 
modules  may  or  may  not  adhere  to  the  specification.  Happily,  one  adherence  function  suffices  for 
each  access  function  (and  hence  for  each  pin).  Unhappily,  this  adherence  function  is  in  general 
much  more  complex  than  the  membership  function  of  Figure  3-3.  In  fact,  the  adherence  function 
can  be  up  to  four-dimensional,  in  that  the  adherence  function  maps  each  (possibly  two- 
dimensional)  input  and  output  of  its  corresponding  access  function  into  the  range  [0,1]  (which 
range  is  here  always  represented  on  the  y-axis  (ordinate)  by  convention). 

For  analysis,  however,  the  chief  concern  is  with  the  two-dimensional  projection  (of  the 
adherence  function)  that  corresponds  to  each  separate  access  function  input  value,  so  that  module 
output  is  graphed  on  the  x-axis  (abscissa)  and  the  adherence  function  value  on  the  y-axis.  On  the 
y-axis  of  such  a  projection  (e.g.,  Figure  3-4),  the  designer  can  choose  intervals  of  adherence  for  the 
specification,  with  each  interval  assigned  an  intuitive  meaning  or  figure  of  merit.  The  intervals 


for  the  adherence  function  output  values  that  are  intercepted  on  the  x-axis  by  these  adherence 
intervals  are  commonly  referred  to  as  the  tolerancet  for  these  outputs.  This  tolerance  concept,  if 
not  often  formalized,  is  also  familiar.  For  example,  the  “plus  and  minus  x%”  color  banding  of 
resistors  is  well-known  in  electrical  engineering.  Even  in  software,  where  the  concept  is  almost 
always  abstracted  away,  one  must  sometimes  acknowledge  tolerances,  as  when  testing  a  floating¬ 
point  variable  for  zero,  e.g. 

t/(abs(x)  <  tol_value)  then  .... 

The  ordinate  of  the  adherence  function  graph  is  not  dimensionless,  as  has  previously  been 
suggested.  Actually,  the  adherence  function  measures  the  marginal  utility  of  reduced  tolerance. 

In  so  doiDg,  it  provides  a  means,  heretofore  unavailable,  for  the  specifier/designer  to  communicate 
to  the  implementer  the  cost  of  suboptimization.  As  such  a  vehicle,  the  adherence  function  might 
be  termed  an  adherence  value  function.  Further  research  is  needed  to  exploit  this  important  con¬ 
cept  to  optimize  its  value  in  the  VLSI  design  process. 

Adherence  functions  can  be  formalized  as  follows.  Let 

V  s  ri 

be  a  value  access  function  in  a  specification.  The  specification  will  then  also  include  an  adherence 
function 

°lv,  l:  S  X  r(  -*  [0,l| 

such  that,  if  v(  (qO)  =  xO,  a[v,  j(qO,x)  equals  1  if  x  =  xO  (the  specified  val  ic)  and  some  other 
value  in  [0,1]  if  x  =jfe  xO.  The  variable  x  represents  an  output  signal,  and  thus  it  may  be  multi¬ 
valued  (a  vector). 

Similarly,  if 

w, :  S  X  d,  -»  S 

is  an  effect  access  function  in  a  specification,  the  specification  also  includes  an  adherence  function 

flv,J:  (S  X  d,)  X  S-  [0,1) 

such  that,  if  w(  (q0,x0)  =  ql,  £[w(  ](q0,x0,q)  equals  l  if  q  =  ql  and  some  other  value  in  [0,1]  if 
q  ql.  Here  the  variable  xO  represents  an  input  signal;  it  too  can  be  a  vector. 


Margin*!  adherence  above  this 
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Figure  3*4.  A  Projection  of  an  Adherence  Function  cr[fj 
for  a  Single  Input  of  an  Access  Function  f. 

Notes: 

1.  X-axis  (abscissa)  measures  output,  state  output  (if  f  is  an  effect  access  function),  or  signal 
variable  output  (if  f  is  a  value  access  function).  xO  is  the  output  value  predicted  by  the 
specification  access  function  f. 

2.  Variable  tolerance  range  for  full  adherence. 

3.  Variable  tolerance  range  for  marginal  adherence. 

4.  The  values  fa  and  ma  are  chosen  by  the  designer;  they  are  provided  in  this  figure  only  to 
illustrate  sample  meanings  of  the  intuitive  concepts  of  "full”  and  “marginal"  adherence. 


Adherence  functions  appear  to  be  complicated  to  use.  Part  of  their  complexity  may  result 
from  the  recognized  detail  explosion  that  has  hampered  efforts  toward  developing  techniques  for 
abstract  interface  specification  of  VLSI  designs  at  refinement  levels  below  the  functional.  But 
adherence  functions  exist  e'  en  at  the  functional  level.  In  functional  specifications,  adherence 
functions  are  degenerate,  however,  and  return  zero  rather  tl.^n  some  other  value  in  [0.1]  for  an 
input  other  than  the  specified  one  (vide  function  1,  Table  3-3).  Thus,  for  functional  specifications 
the  access  function  itself  suffices  for  the  adherence  function,  masking  the  adherence  function's 


existence.  Identifying  the  adherence  functions  is  necessuy  only  in  more  refined  specifications; 
however,  if  the  existence  of  these  functions  is  acknowledged  at  the  functional  level,  the 
specification  refinement  process  can  be  visualised  more  consistently.  (In  section  3.4  some  ways 
will  be  suggested  to  simplify  adherence  function  usage  without  sacrificing  precision.) 

The  definitions  of  "abstract  interface  specification’’  and  “adherence’’  can  now  be  completed, 
as  follows: 

Definition.  An  IC  module  abstract  interface  tpecification  is  a  6-tuple 
<P,  S,  V,  W,  VAF,  WAF>,  where 
P  is  a  set  of  pint, 

S  is  a  set  of  interna/  slates, 

V  is  a  set  of  value  access  functions, 

W  is  a  set  of  effect  access  functions, 

VAF  is  a  set  of  value  adherence  functions,  and 
WAF  is  a  set  of  effect  adherence  functions. 

In  passing,  we  should  recognize  also  the  value  of  informally  including  in  the  specification  a  set  of 
English-language  assumption*  (Heni78,  BritSla).  These  assumptions  (see  section  2.4.3)  provide  no 
essential  abstract  interface  information,  but  they  do  set  the  context  for  the  formal  content  of  the 
specification  and  do  so  in  a  way  that  can  be  easily  assimilated  by  reviewers.  In  addition,  they 
play  an  important  role  in  communicating  the  content  of  the  specification  to  non-technically- 
oriented  reviewers,  who  may,  thus  enlightened,  be  able  to  provide  valuable  feedback. 

If  a  specification's  adherence  functions  are  constructed  appropriately,  a  consistent  interpre¬ 
tation  of  the  concept  of  adherence  can  be  applied  not  only  across  all  inputs  of  a  single  access 
function,  but  indeed  across  all  access  functions  in  the  specification.  The  result  will  be  that,  for 
each  k,  the  situations  in  which  adherence  functions  return  values  in  the  interval  [k,l|  have  a  com¬ 
mon  meaning. 

Definition.  Let  MS  =  <P,S,V,W,VAF,WAF>  be  a  module  specification,  and  let  M  be  an  IC 
module.  A  pin  p  of  M  is  said  to  k-adhere  to  specification  MS  if 


(1)  when  p  corresponds  to  an  access  function  v  <  V,  for  all  qO  c  dom(v),  if  M  is  in  state  qO 
and  if  x  is  the  output  when  v  is  applied  to  M,  then 

o|v)(qO,x)  >  k; 
and 

(2)  when  p  corresponds  to  an  access  function  w  e  W,  for  all  pairs  (qO,xO)  e  dom(w),  if  M  is  in 
state  qO,  if  xO  is  the  input  to  M,  and  if  this  causes  M  to  make  a  transition  to  state  q,  then 

£|wl(q0,x01q)  >  k. 

Further,  module  M  K -adheres  to  specification  MS  if  K  is  the  smallest  k  for  which  any  pin  p  in  M 

k-adberes  to  MS. 

Some  important  corollaries  of  these  definitions  can  be  noted. 

(1)  If  k-adberence  is  to  be  established  by  simulation,  exhaustive  simulation  is  required.  Modules 
must  therefore  be  kept  small  to  avoid  the  penalties  of  the  combinatorial  explosion.  For¬ 
tunately,  having  small  modules  also  contributes  to  intellectual  control,  and  systems  of  hun¬ 
dreds  of  small  software  modules  have  been  found  to  be  easier  to  specify  and  manage  than  have 
systems  of  tens  of  larger  modules  [Brit81b,  Parn83b,  Parn84]. 

(2)  However,  k-adherence  need  not  be  established  by  simulation.  If  a  module’s  behavior  and  per¬ 
formance  can  be  predicted  analytically  (e.g.,  see  [Barr84]),  the  definition  can  be  tested  using 
these  means. 

(3)  Adherence  to  a  functional  specification  is  1-adherence.  This  concept  is  meaningful  because  1- 
adherence  and  its  implicit  adherence  functions  are  well  understood.  To  provide  the  same 
degree  of  intuition  for  k-adherence,  the  specifier  must  construct  adherence  functions  carefully 
to  reflect  (a)  the  degree  of  tolerance  in  a  specification  and  (b)  the  impact  of  incomplete  adher¬ 
ence.  For  example,  if  a  “cushion"  is  intentionally  built  into  a  specification,  the  adherence 
function  should  permit  a  wide  degree  of  deviation  before  it  falls  from  a  value  of  1.  As  another 
example,  pin  behavior  may  fall  off  as  the  square  of  a  voltage  deviation  but  only  linearly  with 
current  deviation.  The  adherence  function  should  reflect  this.  Research  is  needed  into  the 
development  of  adherence  functions  that  both  meet  these  criteria  and  also  yield  values  that 
lend  meaning  to  k-adberence  across  a  wide  spectrum  of  designs. 


S.t  Example. 


An  example  will  clarify  the  distinctions  of  the  proposed  interface  specification  technique. 
Figure  3-5  provides,  using  a  clear-box  specification  method,  a  specification  of  a  register  cell  used 
in  the  recent  development  of  the  WAfer-Scale  Systolic  Processor  [Hedl83,  Hedl84b,  Cole85]  at  the 
University  of  North  Carolina.  The  logical  operations  specified  for  this  cell  are  SHIFT,  invoked  by 
a  value  of  1  on  the  th  signal,  and  HOLD,  invoked  by  a  value  of  0. 

Figure  3-6  shows  how  this  same  module  is  specified  in  the  proposed  method.  The  major  sec¬ 
tions  of  the  specification  are  as  follows: 

(1)  Assumptions.  This  informal  list  states  in  prose  the  fundamental  assumptions  underlying  the 
module’s  definition.  As  in  Parnas's  method,  the  assumption  list  can  contain  statements  about 
required  subsets,  expected  changes,  and  behavior  in  the  face  of  undesired  events. 

(2)  Specification  Level.  Identification  of  the  syntactic  and  semantic  levels  of  the  specification’s 
generic  state  type. 

(3)  Pin  and  Internal  State  Variable  Summaries.  This  list  contains:  (a)  the  names  of  the  module 
pins  and  internal  state  variables;  (b)  the  identity  of  the  access  function  corresponding  to  each 
pin;  and  (c)  a  "call/definition”  indicator  that  tells  whether  the  access  function  is  defined  in 
this  specification  or  merely  called. 

(4)  State  Variable  Attribute  Initialization.  The  generic  state  type  requires  particularization  by 
the  initialization  of  its  attribute  values.  For  example,  the  generic  state  type  might  define  state 
variables  with  capacitive  load  C;  in  this  section,  instances  of  this  type  would  be  particularized 
by  the  assignment  of  a  value  to  C. 

(5)  Access  Function  Definitions.  An  abstract  statement  of  the  actions  to  be  performed  on  invoca¬ 
tion  of  each  access  function.  To  enhance  robustness  of  the  specification  under  refinement,  this 
statement  should  be  as  data-type  invariant  as  possible. 
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NAME  WASP  1.0,  July  15,  1984 

plashin  —  LSSD  input  driver 
Variations:  pi  ash  in  a 
SYNOPSIS 

LSSD  memory  element:  static  memory  cell  that  can  convert 
to  a  shift  register. 

USAGE 

This  is  the  basic  shift  register  memory  cell  used  in  both 
the  MinAlu  and  the  Switch. 

PROPERTIES 

Size  delta  x  *=  18  lambda  delta  y  »  90  lambda 
Power  Consumption  (to  be  determined) 

PINS 

p2sh  input  active  phi2  restored  control 

p2shbar  input  active  phi2  restored  control 

plshbar  input  unclocked  restored  control 

scin  input  active  phi2  steered  scan  data  input 

scout  output  active  phi2  steered  scan  data  output 

routbar  output  unclocked  restored  data  output 
DESCRIPTION 

Static  memory  cell  that  can  function  as  a  shift  register. 

Typically  controlled  by  a  single  shift  signal,  sh, 
sh— 0  static  memory 

sh=l  shift  register 

This  usage  assumes  the  following  logic  for  the  control 
signals: 

p2sh  =  phi2  AND  sh 
p2shbar  =  phi2  AND  (NOT  sh) 
plshbar  =  phil  OR  (NOT  sb) 

Data  are  shifted  from  left  to  right. 

NOTES 

1)  Control  signals  can  be  generated  by  cell  rwcntl. 

RELATED  DOCUMENTATION 
See  manual  pages  for  rwcntl  and  LSSD  memory. 
TESSELLATION 

Cells  abut  horizontally  to  form  registers  of  arbitrary  length 
that  shift  from  left  to  right. 

ORIG'N 

Originally  derived  from  Stanford  Cell  Library  (old  version) 
cell  PlaShiftln  (CIF  ID  81).  Minor  modifications  by  Hedlund 
(UNC)  and  Lospinuso  (UNC). 

LOGIC  DIAGRAM 


Figure  3-5.  A  Clear-Box  Cell  Specification  (Hed!84aj. 


M 

(6)  Data  Type  Definitions.  Here,  the  generic  state  type’s  objects  and  operations  are  defined. 

These  definitions  are  level-specific,  but  they  can  be  reused. 


plash  in 

Module  Specification 


ASSUMPTIONS 

Synopsis:  LSSD  memory  element:  static  memory  cell  that  can  convert  to  a  shift  register. 

Size:  delta  x  — *  18  lambda;  delta  y  *=  90  lambda 
Description-01:  Data  are  shifted  from  left  to  right. 

Description-02:  p2sh  =  p2  AND  sh;  p2shbar  =*  p2  AND  (NOT  sh);  plshbar  =  pi  OR  (NOT 

sh) 

Notes-01:  Control  signals  can  be  generated  by  cell  rwcntl. 

Related_Documentation:  See  manual  pages  for  rwcntl  and  LSSD  memory. 

Tessellation:  Cells  abut  horizontally  to  form  registers  of  arbitrary  length  that  shift  from  left  to 
right. 

Origin-01:  Originally  derived  from  Stanford  Cell  Library  cell  PlaShiftln  (CIF  ID  81). 

Origin-02:  Minor  modifications  by  Hedlund  (UNC)  and  Lospinuso  (UNC). 

SPECIFICATION  LEVEL2 

Semantic:  4-strengtb 
Syntactic:  immaterial 

PINS 


Name 

AccFn 

C/D 

scin 

G_ScanIn 

C 

scout 

P_ScanOut 

D 

routbar 

P_DataOut 

D 

p2sh 

S_Shift 

D 

p2shbar 

S_Hold 

D 

plshbar 

S_Recirculate 

D 

INTERNAL  STATE  VARIABLES 

left 

right 

STATE  VARIABLE  ATTRIBUTE  INITIALIZATION 
None. 

ACCESS  FUNCTIONS 
G_ScanIn:  none 


*  See  T»blt  3-2 


Figure  3-6.  Proposed  Specification  for  plathin. 


P  DataOut: 

.  .  . . 

#/•  Access  function  P_DataOut: 

#*/ 

!  routbar  ■«  ROUTBAR  -»  skip;  /*  Null  access  function  •/ 
P  Sc  an  Out: 

#?**••••• . . . 

#/*  Access  function  P  ScanOut: 

#*/ 

|  !  scout  =  SCOUT  — *  skip; 

S  Shift: 


#>••• . . . * . . . *•**••**/ 

#/*  Access  function  SjShift: 


#*/ 

|  r  P2SH  -  p2sh  - 

#  SS  =  signal(P2SH); 

#  ST  —  signal_threshold(P2SH); 
[  SS  >=  ST  - 

?  SC1N  =  scin; 

#  steer(SCIN,P2SH.Ieft); 

#  inv(Mt, ROUTBAR); 

|  SS  <  ST  -*  skip; 


S_Hold: 

ft/****  ************  *•••••••***•***< 

#/*  Access  function  S_Hold: 

#*/ 

|  T  P2SHBAR  =  p2shbar  — 

#  SH  =  signal(P2SHBAR); 

#  ST  =  sign al_threshold(P2SHBAR); 

|  SH  >=  ST  - 

#  steer  (SCOUT, P2SHBAR, left); 

|  SH  <  ST  -  skip; 


/ 


S_Recirculate: 

ft/* ****************************************** ************  I 

#/•  Access  function  S_Recirculate: 

#  */ 

|  ?  P1SHBAR  =  plshbar  -» 

#  SR  -  signal(PlSHBAR); 

#  ST  =  sign  al_th  resh old (P 1 SHB AR ); 

|  SR  >=.  ST  - 

#  steer  (ROUTBAR, P1SHBAR, right); 

#  inv  (right,  SCOUT); 

|  SR  <  ST  -*  skip; 


Figure  3-6.  Proposed  Specification  for  platkin.  (Cont'd) 


DATA  TYPE  DEFINITIONS 
/*  Data  Type  Definition: 

•  Four-strength  semantic  refinement  level. 

•  Immaterial  syntactic  refinement  level. 

• 

*  At  this  level  the  state  variable  data  structure  is 

*  typedef  struct  stvar  { 

*  int  sigvartyp; 

*  int  sigfval; 

*  int  sigstrength; 

*  } STVAR  ; 

*  with 

*  sigvartyp  =  variable  type  (4  ■■  four-strength/immaterial); 

*  sigfval  =  functional  value  in  {0,1,9  (=  undefined)}; 

*  sigstrength  =  signal  strength  in 

*  {0  (=  unknown), 

*  1  (=  floating), 

*  2  (—  steered), 

*  3  (=  restored)} 

*  with  signal  strength  codes  semantically  ordered 

*  (i.e.,  i  >  j  -»  strength  i  >  strength  j). 

*/ 

#define  INFINITY  65535 

inv(input, output) 

STVAR  ‘input,  ‘output; 

{ 

output— *sigv  arty  p  =  input— » sigvartyp; 
output— *sigfval  = 

(input— ►sigfval  ==  9)  ?  9  :  (1  -  input-*sigfval); 
if  (input-*sigvartyp  <  4)  output-*sigstrength  =  0; 
else  output-*sigstrength  =  (input-»sigstrength  >=  2)  ?  3  :  0); 
return; 

} 

int 

signal(input) 

STVAR  ‘input; 

{ 

return(INFINITY); 

} 

int 

signal_threshold(input) 

STVAR  ‘input; 

{ 

return(O); 

} 


Figure  3-6.  Proposed  Specification  for  plathin.  (Cont'd) 


68 


steer(input,  control,  output) 

STVAR  ’input,  ’control,  *output; 

{ 

output-*sigvartyp  input— ►sigvartyp; 

output— ►sigfval  (control— ►sigfval  «  1)  ?  input— ►sigfval 

:  output-esigfval; 

if  (input-»sigvartyp  <  4)  output— ►sigstrength  **  0; 

else  output— ►sigstrength  *=  (input— ►sigstrength  >**  2)  ?  2  :  0); 

return; 

} 


ADHERENCE  FUNCTION  DEFINITIONS 
Access  Fn  f  Adherence  Function  a[f] 


P_DataOut 

«(q.x) 

=  1  if  x— ►sigfval  =  P_DataOut(q)— »sigfval 
and  x— »sigstrength  >  2; 

=  0  otherwise. 

P_ScanOut 

a(q,x) 

=  1  if  x— ►sigfval  =*  P_ScanOut(q)-»sigfval 
and  x-esigstrength  >  2; 

=  0  otherwise. 

S_Shift 

a(q.s.q’) 

=  1  if  q’  =  S„Shift(q,s); 

=  0  otherwise. 

S_HoId 

<*(q,M') 

=  1  if  q'  =  S_Hold(q,h); 

*=  0  otherwise. 

S_Rec  ire  u  late 

«(q.rq') 

=  1  if  q’  =  S__Recirculate(q,r); 

0  otherwise. 

w"*  ■*,  V*  •»' „  s' .  I 


Figure  3-6.  Proposed  Specification  for  plathin.  (Cont'd) 


Several  distinguishing  features  can  be  noted  in  Figure  3-6.  In  the  first  place,  module  seman¬ 
tics  are  defined  on  a  per-pin  basis,  rather  than  globally.  Such  a  partitioning  of  module  semantics 
makes  the  specification  easier  to  construct  and  verify  intellectually;  it  also  reduces  the  combina¬ 
torial  complexity  of  the  formal  verification  task  in  two  ways.  First,  each  pin's  semantics  a:e  only 
a  subset  of  module  semantics,  making  the  verification  task  simpler  at  each  pin.  Also,  for  IC 
modules,  physical  fabrication  constraints  (i.e.,  pin  count  restrictions)  will  continue  to  provide 
motivation  to  encapsulate  module  subfunctions,  keeping  low  the  number  of  separate  pin 
verifications  |Moor84j. 

Figure  3-6  illustrates  this  partitioning.  The  module  functions  SHIFT  and  HOLD  have  been 
redefined  into  the  access  functions  P_ScanOut  (which  Putt  a  value  on  the  tcout  pin),  P_DataOut, 
and  the  three  qualified  clock  access  functions  S_Shift,  S_Hold,  and  S_Recirculate  (which  set  the 
state  variables  left  and  right  according  to  an  input  value  received  on  the  p£sh,  pSthbar,  and 
plshbar  pins  respectively).  The  sixth  access  function  G_ScanIn  is  not  defined  in  the  specification, 
but  appears  instead  as  a  function  call  (?  left  =  Scanln)  in  the  definition  of  the  function  S_Shift. 
(Access  functions  have  been  expressed  in  the  Communicating  Sequential  Processes  (CSP)  notation 
[Hoar78],  which  will  be  explained  in  section  3.3.  The  question  mark  in  CSP  is  an  input  operator.) 

Note  that  as  a  specification  is  refined,  it  may  be  necessary  to  add  additional  pins:  for  exam¬ 
ple,  power  and  ground  pins  will  generally  not  appear  in  less-refined  specifications,  nor  will  pins  at 
both  ends  of  busses.  Because  the  specification  is  defined  on  a  per-pin  basis,  however,  the  change 
required  by  the  addition  of  new  pins  is  reduced.  Power  and  ground  pins  generally  do  not  require 
access  functions,  as  their  information  of  concern  is  purely  syntactic  until  one  arrives  at  the  most 
refined  specification  levels;  even  at  these  levels,  their  access  functions  would  be  easy  to  construct. 
As  for  the  other  pins,  most  specifications  contain  one  reference  (definition  or  call)  to  an  access 
function  for  each  logical  pin  in  the  module.  While  some  pins  (e.g.,  control  busses  such  as 
plshbar)  may  be  implemented  with  more  than  one  physical  termination,  for  less  refined 
specifications  the  access  function  is  assumed  to  define  the  behavior  at  all  physical  pin  termina¬ 
tions.  If  it  does  not,  as  perhaps  for  long  poly  control  busses,  new  access  functions  can  be  defined 
for  each  termination  whose  behavior  differs.  Usually,  however,  the  scope  of  these  access  functions 
in  module  state  is  small,  and  hence  a  small  amount  of  change,  if  any,  is  required  in  adjacent 
acc  ss  functions. 
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At  least  oae  disadvantage  accrues  from  this  partitioning  of  module  semantics  into  per-pin 
components:  global  module  constraints,  such  as  power  consumption,  current  draw,  tessellation, 
and  aspect  ratio,  are  difficult  to  specify.  Possible  approaches  include  (1)  apportioning  these  con¬ 
straints  among  the  pins  and  (2)  constructing  distinguished  state  variables  ("constraint  variables"), 
global  to  all  access  functions,  that  express  these  constraints.  Constraint  variables  will  probably 
differ  in  type  from  the  generic  state  type,  complicating  the  specification,  but  they  will  exist  in  lim¬ 
ited  numbers.  Further  research  is  needed  to  determine  the  best  way  to  specify  global  constraints 
within  the  proposed  approach. 

A  second  thing  to  note  about  Figure  3-6  is  that  it  is  executable.  Using  a  CSP  interpreter, 
one  can  obtain  an  approximrtion  of  module  performance  at  any  level  of  specification  definition; 
such  an  approximation  can  be  used  as  a  frame  for  design  verification.  As  an  example,  Figure  3-7 
illustrates  the  role  of  a  “Specification  Interpreter"  based  on  the  CSP/84  implementation  of  CSP 
[JazaSOa,  JazaSOb,  Midd84,  Midd85]  which  was  used  experimentally  in  this  research  to  approxi¬ 
mate  the  behavior  of  CSP  access  functions  (see  Appendix  B). 

Third,  the  specification  in  Figure  3-6  is  malleable;  that  is,  by  undergoing  specification 
refinement  it  can  continue  to  serve  as  a  frame  for  verification  throughout  the  design  life-cycle. 
Ideally,  such  refinement  affects  only  the  data  type  and  adherence  function  definitions:  there 
should  be  no  need  to  change  access  function  definitions,  a  fact  that  strengthens  the  robustness  of 
the  specification  under  refinement.  Furthermore,  if  specification  refinement  is  evolutionary,  com¬ 
positions  of  modules  specified  at  different  levels  of  refinement  can  be  interpreted  consistently.  For 
example,  the  definitions  of  the  operators  ‘inv’  and  ‘steer’  have  been  enriched  to  carry  out  run-time 
typing  of  their  inputs,  and  thus  they  can  process  variables  of  less  semantic  complexity.  The 
added  overhead  of  such  run-time  typing  is  justified  for  specification  interpretation,  which  need  cot 
be  extremely  efficient;  and  the  added  complexity  that  run-time  typing  adds  to  data  type  definition 
can  be  justified  because  data  type  definitions,  once  completed,  are  reusable  and  can  be  catalo¬ 
gued. 

Fourth,  the  specification  in  Figure  3-6  is  both  adequate  and  precise.  Adequacy  is 
guaranteed  through  specification  refinement,  which  in  turn  can  be  accomplished  by  evolutionary 
refinement  of  the  generic  state  type.  Precision  exists  at  all  specification  levels  through  the  formal 
definition  of  access  functions,  the  generic  state  type,  and  adherence  functions. 


Figure  3-7.  Role  of  Specification  Interpreter 
in  the  VLSI  Design  Process. 

(Design  representations  are  listed  in  the  left  column,  intermediate  results  for  verification  purposes 
in  tbe  right.) 


Finally,  the  specification  in  Figure  3-6  is  long  —  four  times  as  long  as  the  clear-box 
specification  in  Figure  3-5.  This  length  is  the  cost  incurred  for  the  benefits  of  clean  partitioning 
and  facilitated  verification,  executability,  malleability,  adequacy,  and  precision.  Section  3.4  will 
contain  a  discussion  of  the  prospects  for  reducing  this  cost.  First,  however,  I  shall  examine  in 
more  detail  some  issues  involved  in  composing  interface  specifications  that  are  constructed  in  the 
proposed  manner. 

S.S  Composition  of  Specifications. 

S.8.I  Synchronization  and  Scheduling. 

As  has  been  noted,  a  chief  advantage  of  a  black-box  specification  method  is  its  clean  separa¬ 
tion  of  architectural  and  implementational  concerns.  However,  the  complexity  of  a  large  black 
box  cannot  be  reduced  by  resorting  to  descriptions  of  its  internal  hierarchy,  for  to  do  so  would 
make  unintended  assumptions  about  its  implementation.  Instead,  I  seek  to  reduce  black-box  com¬ 
plexity  in  two  ways:  first,  by  providing  an  abstract  model  of  its  operation;  and  second,  by  parti¬ 
tioning  its  semantics  and  specifying  them  on  a  per-pin  basis  rather  than  globally.  Because  the 
entirety  of  the  abstract  state  model  might  be  large,  it  is  usually  undesirable  that  any  pin  effect 
access  function  should  be  required  to  update  any  significant  portion  of  the  state.  Instead,  these 
access  function  effects  should  be  localized  to  reduce  function  complexity  and  to  improve  intellec¬ 
tual  control,  aiding  verification. 

This  requirement  necessitates  the  introduction  of  some  mechanism  for  sequencing  the  appli¬ 
cation  of  access  functions.  A  simple  example  illustrates  the  problem.  Suppose  a  module  has  three 
state  variables,  v,  ,  v„  ,  and  v.  ,  and  two  effect  access  functions,  f,  and  f„  ,  where  the  effect  of  anv 
call  to  fj  moves  the  value  in  vt  to  v  .  Obviously  the  call  sequence  fj  ,  f„  produces  a  potentially 
different  result  in  vg  than  does  the  sequence  f2  ,  fr  At  the  same  time,  to  maintain  simplicity  one 
does  not  wish  to  involve  fj  with  testing  either  the  value  in  vs  or  the  status  of  invocation  of  f2. 
Another  expedient  is  required. 

Put  another  way,  a  mechanism  is  needed  to  schedule  and  synchronize  the  invocation  of 
dependent  sequences  of  independent  actions  in  a  way  that  produces  consistent  and  predictable 
results.  In  a  landmark  paper  [Hoar78],  Hoare  proposed  a  notation,  called  Communicating  Sequen¬ 
tial  Processes  (CSP),  which  integrated  previous  work  on  this  problem.  In  Hoare’s  words,  the 
essential  proposals  of  CSP  are  the  following: 
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(1)  Dijkstra's  guarded  commands  are  adopted  ...  a*  sequential  control  structures,  and  as  the  sole 
means  of  introducing  and  controlling  nondeterminism. 

(2)  A  parallel  command  ...  specifies  concurrent  execution  of  its  constituent  sequential  commands 
(processes).  ...  They  may  not  communicate  with  each  other  by  updating  global  variables. 

(3)  Simple  forms  of  input  and  output  eommand  ...  are  used  for  communication  between  concurrent 
processes. 

(4)  Such  communication  occurs  when  one  process  names  another  as  destination  for  output  sad  the 
second  process  names  the  first  as  source  for  input. ...  There  is  as  automatic  buffering:  in  general, 
an  input  or  output  command  is  delayed  until  the  other  process  is  ready  with  the  corresponding 
output  or  input.  Such  delay  is  invisible  to  the  delayed  process. 

(5)  Input  commands  may  appear  in  guards.  A  guarded  command  with  an  input  guard  is  selected 
for  execution  only  if  and  when  the  source  named  in  the  input  command  is  ready  to  execute  the 
corresponding  output  command.  If  several  input  guards  of  a  set  of  alternatives  have  ready 
destinations,  only  one  is  selected  and  the  others  have  as  effect,  but  the  choice  between  them  is 
arbitrary.  ...  [Hoar78] 

Following  another  suggestion  of  Parnas  [NPS79],  I  chose  CSP  as  a  notation  for  expressing 
scheduling  and  synchronization  for  the  proposed  specification  method.  The  alternative,  which  is 
used  in  Simula,  ClassC,  and  some  commercial  IC  simulators,  is  to  use  an  event  list  driven  by  a 
global  clock.  Such  usage  focuses  the  specification  around  a  global  issue,  the  passage  of  simulated 
time,  hindering  the  localization  of  concerns  that  facilitates  change  management.  CSP,  on  the 
other  hand,  explicitly  separates  synchronization  and  scheduling  from  the  description  of  process 
function.  The  potential  for  reducing  the  complexity  of  change  through  such  a  separation  of  con¬ 
cerns  is  just  beginning  to  be  noticed  in  the  VLSI  research  community  (see,  e.g.,  [Lieb85]). 


To  use  CSP  in  IC  module  specification,  one  collects  module  access  functions  into  a  single 
CSP  process,  which  corresponds  to  the  module  and  is  called  the  “module  process.”  The  (CSP) 
module  process  incorporates  elements  of  the  module  specification  in  the  format  shown  in  Table 
3-1.  As  can  be  seen,  the  module  process  contains  all  the  module  specification  except  for  the 
level-specific  information:  data  type  definitions  (which  could  be  included,  but  which  are  generally 
omitted  for  brevity)  and  adherence  function  definitions. 


The  core  of  the  module  process  is  the  access  function  definition  list.  As  Table  3-1  indicates, 
this  list  consists  of  a  sequence  of  guarded  definitions  of  the  form 

<pin_guard>  — »  <statement_list> 

As  has  been  stated,  in  a  specification  there  is  a  one-to-one  relationship  between  module  pins  and 
access  functions;  however,  not  every  pin  has  an  access  function  definition  in  the  module  process. 
Instead,  definitions  are  included  only  for  (1)  input  pins  of  effect  access  functions,  and  (2)  output 
pins  of  value  access  functions.  The  remaining  pins  are  referenced  from  within  these  definitions  as 
access  function  colie.  A  “Call/Definition  (C/D)”  indicator  has  been  included  in  the  pin  summary 
(see  Figure  3-6)  to  reflect  whether  an  nccess  function  call  or  definition  is  included  in  the 
specification. 


<module_process> 

procttt  module_name  :: 

<  pin_declaration_list  > 

<  state_v  ar_dec  lar  ation_list  > 

<  access_function_defn_list> 
end  procttt 

<pin_declaration_list> 

<pin_declaration>  |  <pin_declaration>  <pin_declaration_list> 

<pin_declaration>  = 

{guarded}  | input  |  output ]  port  <sig_type>  pin_id  ; 

<sig_type>  ::=  (Varies  with  specification  refinement  level.  See  data  type  definitions  for  the 
particular  level  desired.) 

<state_var_declaration_list>  ::=  <state_yar_declaration> 

|  <state_var_declaration>  <state_var_declaration_Iist> 

<state_var_declaration>  ::=  (Varies  with  specification  refinement  level.  See  data  type 
definitions  for  the  particular  level  desired.) 

<access_function_defn_list>  ::= 

<state_var_initialization_stateraent_list> 

»[<guarded_defn_Iist>| 

<VB>  ::=  | 

<guarded_defn_list>  ::= 

<guarded_defn>  j  <guarded_defn>  <VB>  <guarded_defn_list> 

(Note  that  a  vertical  bar,  <VB>,  must  separate  guarded  definitions.) 

<guarded_defn>  ::=  <pin_guard>  — *  <statement_list> 

<pin_guard>  ?  state_varjd  =  pin_id 
|  !  pin_id  =  state_var_id 

Table  3-1.  Partial  Syntax  of  a  CSP/84  Module  Process 
(Jaza80a,  Jaza80b,  Midd85], 

(Expansions  for  <state_var_initialization_statement_list>  and  <statement_list>  can  be 
obtained  from  the  references.) 


Segregating  the  semantics  of  synchronization  and  scheduling  into  the  pin  guard  separates 
them  from  the  access  function's  behavior.  Thus,  the  module  process  body  consists  of  an  infinite 
polling  loop  (represented  by  the  notation  *[<guarded_defn_list>|),  a  loop  that  tests  each  of  the 
pin  guards  non-deterministically  to  determine  whether  a  call  has  been  made  of  that  access 


function  from  outside  the  module.  If  a  call  has  been  made,  the  <statementjist>  associated  with 
the  access  function  is  executed,  including  any  embedded  access  function  calls;  otherwise,  polling 
continues.  In  Figure  3-6,  the  outer  syntactic  brackets  of  this  loop  have  been  omitted,  but  the 
vertical  bar  that  separates  access  function  definitions  has  been  retained  to  show  bow  the  access 
functions  making  up  the  <guarded_defn_list>  are  intended  to  be  concatenated  into  this  list. 

Returning  to  the  question  posed  at  the  beginning  of  this  section,  then,  how  are  access  func¬ 
tions  to  be  scheduled  in  a  consistent  and  predictable  way  using  CSP?  No  additional  mechanism  is 
needed.  One  simply  introduces  in  composition  other  CSP  module  processes  that  schedule  access 
function  execution;  through  appropriate  call  sequences.  In  Figure  3-6  such  an  external  call  is 
illustrated:  the  definition  of  access  function  S_Shift  contains  the  statement 

?  SCIN  =  scin; 

which  is  a  call  of  the  (implicit)  value  access  function  G_ScanIn  (for  “Get  Scanln”).  As  part  of 
the  module  composition,  the  scin  input  pin  has  been  matched  (through  a  separate  set  of  port-to- 
port  connection  declarations  called  a  channel  file)  with  an  output  pin,  say  P,  on  an  adjacent 
module.  When  G_ScanIn  is  called  in  the  execution  of  function  S_Shift,  a  call  is  immediately 
issued  through  the  channel  file  correspondence  to  the  (value)  access  function  for  pin  P,  which  in 
turn  executes  and  returns  a  value  to  the  scin  pin.  This  value  is  then  input  to  the  state  variable 
SCIN  to  complete  the  "?  SCIN  —  scin;”  function  call,  and  access  function  S_Shift  proceeds. 

The  module  process  is  therefore  an  information  hiding  module  in  Parnas's  s  use  of  the  term. 
It  accomplishes  the  objective  of  separating  architectural  and  implementational  concerns,  because 
access  functions  are  only  an  abstract  representation  of  module  behavior.  Moreover,  the  module 
process  is  attractive  as  a  specification  because  synchronization  and  scheduling  concerns  are  clearly 
separated  from  access  function  definitions.  Finally,  because  this  separation  has  been  made,  and 
because  module  behavior  is  specified  on  a  per-pin  basis,  individual  specifications  are  small  and 
therefore  easily  comprehended  and  verified,  even  with  exhaustive  simulation. 

Before  proceeding  to  discuss  the  composition  of  specifications  further,  I  will  enumerate  some 
issues  I  encountered  in  using  CSP  as  an  interface  specification  notation  in  general  and  as  an  access 
function  scheduling  and  synchronization  mechanism  in  particular. 


8.9. 1.1  Power  of  CSP  at  a  Notation  for  Interface  Specification. 


At  do  time  during  this  research  were  VLSI  interface  constructs  encountered  that  could  not 
be  represented  in  the  CSP  notation.  That  CSP  should  be  equal  to  the  task  of  representing  these 
constructs  is  not  surprising,  because  modern  programming  languages  (such  as  APL,  C,  and  Pascal) 
have  been  successfully  used  for  this  purpose,  and  CSP  possesses  all  the  expressive  power  of  these 
languages  in  its  sequential  process  description  facility.  Additionally,  of  course,  CSP  has  a 
separate  mechanism  for  scheduling  and  synchronization  of  these  processes. 


Two  examples  of  CSP's  power  for  specification  follow.  In  the  first,  suppose  one  wishes  to 
specify  a  sequence  of  actions  when  a  signal  SIG1  is  high  (1),  another  sequence  when  it  is  low  (0), 
and  a  null  sequence  when  it  is  undefined.  CSP  represents  this  specification  as  follows  (in  CSP/84 
notation): 


(  SIG1  ==  1  — *  <statement_list_l> 

|  SIG1  ==  0  -»  <6tatement_list_2> 

|  ((S1G1==1)||(SIG1==0))  -  skip; 

/*  Null  access  function  •/ 


1 


If,  on  the  other  hand,  if  one  wished  to  specify  that  an  undefined  value  of  SIGl  is  not  acceptable, 
he  could  have  eliminated  the  alternative  leading  to  “skip."  This  would  cause  the  process  to  ter* 
minate  on  testing  of  an  undefined  value  for  SIGl.  As  a  better  expedient,  the  designer  could  “pol¬ 
ice”  this  condition  by  replacing  “skip"  with  a  trap  to  an  error  routine. 


A  second  example  illustrates  the  specification  of  timing  constraints  in  CSP.  The  WASP  1.0 
design  [Hedl84a]  contained  a  signal  called  “mg!"  that  was  specified  to  rise  and  fall  only  on  the 
leading  edge  of  the  “phi2gl"  clock.  This  constraint  can  be  represented  in  CSP  simply  by  con¬ 
structing  the  access  function  definitions  in  such  a  way  that  the  specified  behavior  is  obtained  only 
if  the  access  functions  are  called  in  the  proper  sequence: 


|  ?  MGL  =  mgl  -*  skip;/*  Null  access  function  */ 
j  T  PHI2GL  =  phi2g]  - 

< statements  using  new  value  of  MGL> 


Finally,  CSP,  or  an  equivalent  notation  possessing  the  power  of  CSP,  seems  a  good 
compromise  as  a  notation  for  abstract  interface  specification  of  VLSI  designs.  It  is  general  enough 
to  be  reasonably  portable  and  does  not  require  any  special  extensions  for  use  in  IC  design 
specification.  However,  it  is  more  explicit  than  general-purpose  programming  languages  (APL,  C, 
Pascal,  etc.)  in  expressing  concurrency  and  in  controlling  complexity  by  effecting  a  clean  parti¬ 
tioning  of  synchronization  concerns  from  the  expression  of  other  aspects  of  module  function. 
Furthermore,  its  ability  to  model  subsets  of  the  design  as  discrete  processes  males  it  more  suit¬ 
able  than  general-purpose  languages  for  evolutionary  refinement  as  the  design  progresses. 

S.S.l.B  Data/ Control  Mapping. 

In  the  specification  of  IC  designs  using  CSP,  a  certain  convention  for  the  mapping  of  data 
and  control  pins  was  useful.  Data  pins  were  best  mapped  using  guarded  CSP  outputs  and 
unguarded  inputs,  and  control  pins  were  best  mapped  using  the  reverse.  Thu  convention  led  to 
the  definition  of  data  pins  by  value  access  functions  and  of  control  by  effect  access  functions. 

One  difficulty  that  can  arise  with  such  a  convention  is  if  a  data  output  from  one  module  is 
used  as  a  control  input  in  another  module,  because  CSP  forbids  the  connection  of  two  guarded 
ports.  A  dummy  module  must  be  constructed  and  inserted  between  the  two  connections;  this 
module  consists  only  of  an  infinite  loop  consisting  of  an  unguarded  input  and  an  unguarded  out¬ 
put  that  passes  along  the  result  of  the  input.  The  introduction  of  such  a  dummy  module  is 
unclean,  and  it  is  not  obvious  that  it  will  always  produce  an  accurate  specification.  Further  work 
is  necessary  here. 

A  second  potential  difficulty  is  deadlock,  which  can  result  from  the  connection  of  unguarded 
inputs  and  outputs  (as  would  be  the  case  if  a  control  output  was  used  as  a  data  input).  Middle- 
ton  [Midd85]  is  modifying  CSP/84,  specifically  for  hardware  modeling,  to  avoid  this  problem  by 
preventing  unguarded  outputs  from  blocking:  if  an  outpu.  is  not  accepted  by  the  time  a  new  out¬ 
put  is  generated,  the  first  output  is  discarded  and  an  error  message  is  sent.  In  the  specifications 
constructed  in  this  research,  I  was  always  able  to  avoid  deadlock,  but  as  before  such  avoidance 
sometime  involved  the  introduction  of  artifice  (such  as  the  forced  "consumption"  of  an  output 
value  that  would  not  be  used).  Such  artifice  also  is  present  in  other  specification  languages,  and  it 
does  permit  the  accurate  specification  of  the  desired  effect.  Nevertheless,  it  is  undesirable  in  that 
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it  Alters  the  correspondence  between  specification  and  implementation. 

S.S.l.S  Aeeen  Function  Extent. 

A  benefit  of  the  proposed  access  function-based  specification  method  is  its  potential  for  com¬ 
plexity  control  through  crisp  partitioning  of  module  function  into  functional  elements  associated 
with  each  pin.  In  some  modules,  however,  not  much  partitioning  can  be  obtained.  This  difficulty 
occurs  in  particular  in  modules  having  many  data  pins  and  few  control  pins,  because  access  func¬ 
tions  for  data  pins  tend  to  be  trivial  (value)  access  functions,  leaving  most  of  the  module  function 
remaining  to  be  partitioned  among  the  few  control  (effect)  access  functions.  Although  different 
abstractions  for  module  state  could  probably  be  constructed  to  overcome  this,  such  construction  is 
not  natural  and  would  probably  diminish  the  attractiveness  of  the  method  to  designers. 

When  a  better  partitioning  can  be  obtained,  another  problem  arises.  This  problem  is,  where 
should  the  line  be  dra>vn  between  the  effects  of  the  various  access  functions  on  the  module  state? 
For  example,  suppose  there  are  two  access  functions  S_mode  and  S_phil  (a  clock),  in  which  the 
“mode"  signal  realigns  the  module  environment  for  a  different  mode  of  operation.  Should,  on  the 
invocation  of  S_mode,  the  entire  module  state  be  reset  for  the  new  mode  in  the  current  clock 
phase,  or  should  the  appropriate  switches  merely  be  set  to  activate  the  new  mode  when  the  next 
clock  access  function  is  invoked? 

The  answer  to  this  question  may  differ  depending  on  whether  a  specification  or  a  simulator 
is  being  constructed.  Recall  that  the  goal  of  a  specification  is  to  provide  a  frame  for  verification, 
and  thus  it  is  required  only  to  describe  one  model  of  correct  operation  and  a  catalog  of  specified 
actions  to  be  taken  when  incorrect  operation  (as  Parnas  says,  an  “undesired  event")  is  encoun¬ 
tered.  The  requirements  for  a  simulator  are  more  stringent:  a  simulator  should  predict  what  will 
occur  even  in  the  presence  of  incorrect  operation.  It  is  important  not  to  confuse  these  two  sets  of 
requirements,  especially  in  that  simulators  can  be  used  as  specifications,  as  has  been  noted  earlier. 
This  is  a  pitfall  of  using  a  simulator  as  a  specification:  of  the  behavior  included  in  the  simulator, 
it  is  possible  that  the  designer  does  not  really  know  which  behavior  to  implement  (the  “correct" 
behavior)  and  which  to  ignore. 


8.8. 1.4  CSP  Bate  Language  Support. 

The  concept  of  the  CSP  notation,  as  explained  by  Hoare  [Hoar78],  does  not  include  a 
language  for  expressing  the  contents  of  the  sequential  process  embedded  in  a  guarded  CSP  com¬ 
mand.  In  particular,  the  implementation  of  CSP  I  used,  CSP/84  [Jaza80a,  Jaza80b,  Midd84],  did 
not  support  closed  subroutines  in  its  base  language.  Even  though  escape  to  the  programming 
language  C  was  provided,  there  was  no  easy  way  that  C  subroutines  could  be  linked  into  the  CSP 
code.  This  omission  was  intentional,  in  that  through  a  robust  subroutine  facility  control  transfers 
could  be  implemented  that  subvert  the  partitioning  of  scheduling  that  is  the  main  attraction  of 
CSP.  Yet,  for  economy  of  coding,  and  particularly  when  greater  levels  of  specification  refinement 
with  their  more  complex  data  types  are  being  modeled,  the  abstraction  that  can  be  gained 
through  closed  subroutines  is  essential  to  understandability  and  cost-effectiveness  of  the 
specification.  For  the  IC  specification  application,  it  is  necessary  that  a  CSP  implementation 
include  at  least  a  restricted  closed  subroutine  capability  in  its  base  language. 

8.8.8  Performance. 

Suppose  two  or  more  modules,  each  kt- adhering  to  their  specifications,  are  composed 
together.  What,  if  anything,  can  be  said  about  the  k-adherence  of  the  composition  if  adherence 
functions  remain  the  same  for  pins  that  appear  in  both  components  and  composition  (Figure  3-8)? 


Ml  ^-adheres  to  its  specification;  M2  kj-adheres  to  its  specification. 

Figure  3-8.  k-adherence  of  a  Composition. 


Before  this  question  can  be  answered,  the  concept  of  “composition  of  specifications"  must  be 
defined:  under  what  conditions  is  the  composition  of  specifications  itself  a  (consistent) 
specification,  and  what  are  the  characteristics  of  such  a  composition?  Let 

M,  -  <P1,S1IVl(W1,V,\F1,WAF1>  and 

H,  “  <p2,s2,v2,w2,vaf2,waf8> 

be  specifications.  Then 

M  =  <P,S,V,W,VAF,WAF> 

is  a  composition  of  and  Mj  if  the  following  conditions  hold: 

(1)  P  is  a  proper  subset  of  Pj  U  P2  ; 

(2)  S  =  S,  U  S2  ;  and 

(3)  For  each  pin  p  t  Pj  U  P2  with  associated  access  function  v(w)  t  Vj  U  V2  (Wt  u  W2  )  and 

adherence  function  a  (0)  t  VAFj  U  VAF2  (WAFj  U  WAF2  ),  p  «  P  -*  v  t  V  (w  t  W)  and 
a  c  VAF  (0  i  WAF).  In  other  words,  external  pins  in  the  composition  retain  their  prior 
access  and  adherence  functions. 

The  composition  is  called  consistent  if  the  difference  (P,  U  P2  )  -  P  is  a  set  of  pairs  of  pins 

{  <P,.PS>  I  P,  <  P,.  P2«Pj} 

such  that 

(a)  Exactly  one  pin  of  each  pair  has  an  associated  access  function  defined  (rather  tiian  called) 

in  V,  U  V2  U  W,  U  W2  ;  and 

(b)  The  access  functions  corresponding  to  the  pins  in  the  pair  are  neither  both  value  nor  both 

effect  access  functions. 

In  a  real  sense,  then,  the  composition  behaves  as  the  sum  of  its  component  parts,  each  retaining 
its  identity  and  behavior  with  no  real  concern  for  its  environment.  Such  information  hiding,  as 
has  been  noted,  was  a  goal  of  this  approach  for  change  management.  The  consistency  condition  is 
really  a  syntactic  check,  akin  to  the  verification  that  inputs  and  outputs  are  connected  in  pairs, 
and  is  not  central  to  the  development.  Note  that  mixed*level  composition  is  also  permitted  by 
this  definition;  as  section  3.1.2.1  indicates,  such  composition  requires  only  the  presence  of 
appropriate  data  type  conversion  facilities. 


Assume,  then,  ns  in  Figure  3-8,  that  two  modules  Ml  and  M2  are  composed,  with  adher¬ 
ence*  kj  and  k2,  respectively.  Observe  that  it  is  possible  for  the  composition  to  exhibit  k- 
adherence  for  k  greater  than  either  k{  or  k3;  for  suppose  pin  Pi  and  P3  both  1-adhere  to  their 
specifications,  pin  P2  kj-adheres  to  the  specification  of  Ml,  and  pin  P4  k2-adheres  to  the 
specification  of  M2.  In  this  case  it  would  be  possible  for  the  composition  to  1-adhere  to  its 
specification  even  though  k{  and  k2  were  substantially  less  than  1.  Shortfalls  in  the  adherences  of 
P2  and  P4  can  be  completely  compensated  for  by  large  safety  margins  built  into  their  correspond¬ 
ing  pins  in  the  adjacent  module.  A  composition,  then  can  exhibit  1-adherence  even  though  nei¬ 
ther  component  does. 

What,  on  the  other  hand,  is  the  worst  case?  Suppose,  in  Figure  3-8,  that  all  pins  of  Ml  kj- 
adhere  and  all  pins  of  M2  k2-adhere,  0  <  k2,  k2  <  1.  Is  it  then  possible  that  the  composition 
might  exhibit  k-adherence  for  k  <  min(kj,k2)?  A  moment’s  reflection  will  show  that  such  a  case 
is  also  possible.  Suppose  all  pins  but  P2  1-adhere  to  their  respective  specifications,  and  P2  0.5- 
adheres  to  the  specifications  of  both  Ml  and  M2.  Then,  by  definition,  both  Ml  and  M2  0.5- 
adhere  to  their  specifications,  but  if  the  diminished  output  from  Ml  at  P2  is  insufficient  to  drive 
the  higher-than-expected  load  in  M2  at  P2,  M2's  external  output  pins  might  not  function  at  all, 
and  the  composition  would  exhibit  0-adherence. 

Given  simply  that  two  modules  kj-adfcere  and  k2-adhere,  then,  the  level  of  adherence  of 
their  composition  cannot  be  predicted  a  priori.  It  would  be  helpful  to  conduct  further  research  in 
this  area  to  determine  the  kinds  of  restrictions  on  design  parameters  that  would  permit  such  a 
prediction  to  be  made.  Udding  [UddiS4]  has  recently  published  some  work  of  this  kind,  which 
provides  tests  for  the  robustness  of  module  delay-insensitivity  through  composition;  additional 
work  is  ongoing  (Moln85|. 

As  an  example  of  the  type  of  results  that  are  needed,  observe  that  a  lower  bound  on  compo¬ 
sition  adherence  can  be  obtained  if  adherence  shortfalls  in  one  module  can  be  "translated”  into 
adherence  shortfalls  in  the  other.  Suppose,  in  Figure  3-8,  that  pin  Pi  k,j-adberes  to  module 
specification  Mj.  Suppose  further  that  signals  Bow  through  both  P2  and  P4  from  Ml  into  M2. 
Finally,  suppose  the  capability  is  available  to  "translate"  the  adherence  shortfalls  (1  -  k2J)  and 
(1  -  k4])  by  decreasing  k2  and  kc  (to,  say,  k’^  and  k’^)  enough  to  raise  k21  and  k41  to  1.  That  is, 
pin  pairs  with  the  adherences  (k^,  ks)  and  (1,  V^)  would  behave  identically;  so  would  pin  pairs 
with  (k41,  k^)  and  (1,  k'4„)  In  this  restricted  case,  then,  the  composition  adherence  is  bounded 


min  (kjj.k’^k^kJ. 


below  by 


S.4  Simptificationg  to  the  Approach  Permitted  by  VLSI  Design  Characteristics. 

As  has  been  shown,  the  abstract  interface  specification  method  proposed  in  the  preceding 
sections  has  many  desirable  attributes;  however,  it  is  also  costly  to  build  and  use.  Much  of  the 
cost  comes  from  the  method's  generality.  In  this  section  1  will  examine  ways  of  exploiting  charac¬ 
teristics  of  VLSI  design  to  reduce  this  cost. 

In  general,  cost  reduction  can  be  pursued  through  restriction  of  the  method  to  certain  stan¬ 
dard  formats  that  are  of  interest  to  VLSI  designers.  First,  for  example,  a  standard  language  can 
be  used  for  expressing  access  functions,  data  type  definitions,  and  access  function  definitions.  A 
standard  language  improves  executability  characteristics  by  capitalizing  on  portable,  optimized 
system  software  developed  for  interpreting  this  language.  Also,  it  improves  intellectual  control  by 
allowing  designers  to  express  function  with  familiar  programming  objects.  In  this  research  I  chose 
to  use  the  language  C  as  such  a  standard,  chiefly  because  my  CSP  interpreter,  CSP/84,  was  C- 
compatible. 


Semantic  Refinement: 

1.  Functional:  Three  values  (0,1, X);  no  signal  strength  information. 

2.  Four-strength:  Three  functional  values  plus  four  signal  strength  levels  (unknown,  floating, 

steered,  restored). 

3.  Drive-load:  One  voltage  level  functional  value  plus  an  average  switching  current  value.  Rise 

and  fall  times  are  symmetric. 

4.  Ell:  Voltage  levels  plus  switching  current  as  reflected  in  nominal  pin  voltages,  resistances, 

capacitances.  Rise  and  fall  times  may  be  asymmetric. 

Syntactic  Refinement : 

1.  Immaterial:  No  geometric  information. 

2.  Pingrid:  (X,Y)  virtual  grid  coordinates  provided  for  each  pin. 


Table  3-2.  Specification  Levels  Used  in  this  Research. 


Next,  one  can  restrict  the  specification  refinement  hierarchy  of  Figure  2-4  to  certain  levels  at 
which  generic  state  types  have  been  predefined.  In  this  way,  each  specification  need  not  contain 
full  definitions  of  these  data  types;  instead,  it  need  only  refer  to  previously  catalogued  definitions. 
The  specification  refinement  level  is  entirely  a  designer  option,  reflecting  his/her  evaluation  of  the 
cost/effectiveness  tradeoffs  inherent  in  constructing  specifications  at  such  a  level.  The  introduc¬ 
tion  of  a  new  level  involves  only  the  definition  of  a  new  generic  state  type  and  a  corresponding  set 
of  adherence  functions  Therefore,  I  make  no  claim  that  the  types  I  have  chosen  are  the  types 
that  should  be  used  in  specification  construction.  Table  3-2  lists  the  specification  levels  that  were 
used  in  this  research;  some  of  their  definitions  have  been  included  in  the  specifications  :n  Appen¬ 
dix  A. 

Together  with  a  standard  generic  state  type  set,  one  can  construct  a  matching  set  of  stan¬ 
dard  adherence  functions  that  operate  on  data  types  at  each  refinement  level.  Table  3-3  contains 
definitions  of  the  standard  adherence  functions  that  were  chosen  for  this  research. 

Why  were  the  functions  in  Table  3-3  chosen?  The  first  function,  labeled  “Functional”  or 
“Spike,"  is  the  implicit  function  inherent  in  all  functional  specifications.  The  others  are  generali¬ 
zations  of  this  function  that  incorporate  various  kinds  of  specification  tolerances.  The  Square 
Band  function  is  a  direct  generalization  of  the  first  function,  but  it  is  insensitive  to  changes  in  k 
when  k-adherence  is  being  measured.  Therefore,  the  Linear  Ramp  function,  which  provides  the 
same  tolerances  as  the  Square  Band  but  which  is  linearly  sensitive  to  changes  in  k,  was  intro- 
duced.  The  Normal  function  has  better  mathematical  properties  for  composition  (e.g.,  continuous 
derivatives)  than  the  other  functions  and  is  also  sensitive  to  changes  in  k;  it  was  considered  to 
investigate  the  utility  of  these  better  properties. 

Finally,  when  such  variables  as  signal  strength  are  being  considered,  one-sided  functions  are 
of  more  use  than  two-sided;  signal  drive  greater  than  some  minimum,  or  signal  load  less  than 
some  maximum,  is  generally  of  no  concern.  Consequently,  one-sided  alternatives  were  also  con¬ 
sidered  for  all  adherence  functions  studied.  Of  course,  an  adherence  function  can  be  a  combina¬ 
tion  of  two-sided  and  one-sided  functions;  in  general,  it  may  be  any  combination  of  functions  on 
its  data  type  components.  For  example,  Figure  3-6  contains  for  the  “P access  functions  a  com¬ 
bination  of  Spike  and  One-Sided  Square  Band  adherence  functions:  the  Spike  function  measures 
adherence  on  the  data  type  component  tigfval,  while  the  One-Sided  Square  Band  function  meas¬ 
ures  adherence  on  the  data  type  component  rigstrength. 


In  summary,  compared  to  Figure  3-6,  the  incorporation  of  these  simplifications  reduces  the 
site  of  an  interface  specification  constructed  with  the  proposed  method.  Nevertheless,  the  cost  of 
a  good  specification  is  high,  and  it  increases  with  the  level  of  specification  refinement.  This  cost 
can  be  justified  only  by  comparing  it  to  the  cost  of  a  bad  specification.  Because  there  have  been 
no  controlled  studies  that  quantify  this  comparison  (nor  are  there  likely  to  be,  because  of  the  cost 
and  difficulty  of  such  studies),  each  designer  must  decide  to  what  extent  his/her  individual  project 
merits  the  use  of  interface  specifications.  The  object  of  this  research  is  to  show  that,  while  good 
abstract  interface  specifications  for  VLSI-scale  design  are  complex,  the  application  of  software 
technology  can  reduce  their  life-cycle  cost.  In  the  following  chapter  I  will  describe  experiments 
which  suggest  how  well  the  proposed  approach  attains  this  objective. 
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CHAPTER  4 

TECHNIQUE  EFFECTIVENESS 

la  chapter  3,  I  reported  on  the  development  of  a  new  approach  to  VLSI  design  abstract 
interface  specification,  illustrating  the  approach  with  a  method  that  employed  it.  This  chapter 
contains  an  evaluation  of  the  approach  using  the  criteria  laid  down  in  section  2.2  for  abstract 
interface  specification  techniques.  Four  separate  categories  of  questions  are  addressed  in  this 
evaluation: 

—  How  well  does  the  method  scale  up  to  VLSI  complexity  levels,  and  is  it  perceptibly  cost- 
effective  at  these  levels? 

—  How  easily  can  specifications  be  refined?  Is  the  method  malleable  and  adequate  throughout? 

—  Is  the  method  spare?  In  particular,  can  geometric  information  be  included  with  the  same 
mechanisms  used  for  functional  and  electrical  information? 

—  How  well  does  the  specification  manage  change?  Does  the  specification  approach  inhibit  the 
propagation  of  change  to  other  parts  of  the  design? 

Experiments  or  studies  were  conducted  to  gain  insight  in  each  of  these  areas.  In  two  subsections, 
this  chapter  describes  first  the  experimental  design  and  then  the  experimental  results. 

4-1  Experimental  Design. 

4-1.1  Scalability  Test. 

Unlike  clear-box  specifications,  which  control  complexity  with  hierarchy,  black-box 
specifications  use  abstraction  as  their  primary  complexity  management  technique.  That  suitable 
abstractions  exist  for  VLSl-scale  modules  is  not  in  question:  examples  of  such  abstractions  are 
many  and  varied.  It  remains  only  to  show  that  abstractions  of  large  modules  can  be  effectively 
used  in  the  proposed  class  of  methods. 

The  only  obstacle  to  such  a  demonstration  is  the  Iraditiona;  one:  the  unavailability  for 
study  of  detailed  public-domain  VLSI  designs.  Such  designs  are  sufficiently  costly  to  develop  that 
they  are  beyond  the  threshold  of  pure  research  laboratories,  and  the  designs  developed  for  the 
marketplace  remain  proprietary.  Rather  than  construct  an  artificial  example  (even  if  the 
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resources  for  such  construction  were  available),  I  chose  to  specify  as  demonstrations  of  the  tech¬ 
nique  SSI,  MSI,  and  LSI  designs  available  locally.  The  extrapolation  of  complexity  factors  present 
in  these  designs  should  provide  insight  into  the  scale  and  perceived  cost-effectiveness  of 
specifications  at  VLSI  levels. 

The  proposed  method  was  used  to  construct  abstract  interface  specifications  of  several 
smaller  designs  as  well  as  a  specification  of  an  LSI  chip,  the  WAfer-Scale  Systolic  Processor 
(WASP)  developed  in  1084  by  Kye  Hedlund  and  his  associates  [Hedl83,  Hedl8-ib,  Cole85|.  Based 
on  the  relative  costs  of  constructing  these  specifications,  estimates  were  made  of  the  scalability 
and  perceived  cost-effectiveness  of  the  method.  These  estimates  are  presented  in  section  4.2.1. 

A  word  about  the  selection  of  designs  for  this  testing  is  in  order.  These  designs,  whose 
specifications  are  shown  in  Appendix  A,  are  all  real  designs,  originally  implemented  in  full-custom 
nMOS  combination  a'  and  sequential  logic.  To  keep  the  experiments  manageable,  the  size  of  the 
experimental  test  set  was  kept  small;  therefore,  certain  types  of  designs  were  not  included.  For 
example,  I  deferred  consideration  of  semi-custom  modules  for  later  research;  however,  because 
semi-custom  design  is  more  constrained  than  full  custom  design,  it  seems  intuitive  that  a  system 
that  manages  complexity  satisfactorily  in  the  full-custom  design  environment  should  translate  well 
to  the  semi-custom  environment.  Abo,  because  the  specification  method  offers  clock  signals  no 
special  semantic  interpretation,  I  made  no  effort  to  include  modules  that  were  specifically 
intended  for  asynchronous  operation.  Finally,  because  the  method  encompasses  analog 
specification  in  the  course  of  refinement,  I  included  no  modules  specifically  intended  for  analog 
implementation. 

The  design  modules  selected  for  this  specification  testing  are  summarized  in  Table  4-1. 

4- I  S  Malleability  Test. 

Whether  or  not  a  specification  is  malleable  depends  on  (1)  its  ease  of  being  refined  with 
detailed  design  parameters  as  these  become  available;  and  (2)  its  service  to  the  designer  at  many 
points  in  the  life-cycle.  The  latter  question  may  be  rephrased,  “Does  the  specification  continue  to 
provide  a  frame  for  verification  at  numerous  design  life-cycle  points?” 


Module  Name  Site 

plashin  7 


fnblk  8  nMOS  combinational  logic.  This  module 

was  evaluated  in  the  context  of  the  'malu' 
(next  entry). 

malu  35  nMOS  microprocessor  ALU;  composition  of 

5  smaller  cells.  This  module  was 
evaluated  in  the  context  of  the 
microprocessor  datapath. 

wasp  3860  Array  of  simple  processors  embedded  in 

a  switch  matrix.  Processors  can  perform 
the  16  Boolean  functions  on  two  bits. 

Table  4-1.  Experimental  Module  Test  Set. 

Source  of  designs:  WASP  |Hedl84a,  Hedl84bj. 

Sizes  are  in  numbers  of  transistors  in  an  actual  implementation. 


Description _ 

nMOS  shift  register  cell  (sequential 
logic).  This  module  was  evaluated  in 
the  context  of  a  shift  register  of 
four  such  cells. 


To  gain  a  feeling  for  how  easy  it  would  be  to  refine  specifications  written  using  the  proposed 
approach,  I  refined  a  design  through  three  different  semantic  levels  and  two  different  syntactic  lev¬ 
els.  1  used  the  number  of  specification  lines  changed  in  each  refinement  as  a  rough  measure  of 
refinement  effort.  These  results  are  presented  in  section  4.2.2. 

Next,  I  executed  the  specifications  thus  constructed  at  each  semantic  refinement  level  and 
evaluated  informally  the  ease  of  comparing  these  outputs  to  simulation  output  from  actual 
designs  at  each  level.  I  further  examined  the  ease  of  verifying  syntactic  specification  components 
with  actual  design  syntax  at  each  syntactic  refinement  level.  The  results  of  these  evaluations  are 
also  presented  in  section  4.2.2. 


4-1.9  Spareneee  Study. 


To  evaluate  the  method's  spareness,  each  specification  element  (enumerated  in  section  3.2) 
was  judged  informally  according  to  the  following  criteria: 

(1)  Is  the  information  included  in  this  section  essential  to  design?  What  part,  if  any,  of  the 
design  could  not  be  accomplished  if  information  in  this  section  were  omitted? 

(2)  Is  the  information  included  in  this  section  redundant,  that  is,  presented  anywhere  else  in 
the  specification?  Could  the  information  in  this  section  be  presented  more  compactly? 

The  results  of  this  analysis  are  presented  in  section  4.2.3. 

4.1.4  Change  Management  Teste. 

The  proposed  method's  effectiveness  in  change  management  was  evaluated  in  three  ways: 

(1)  (Vertical  Change  Propagation).  First,  I  changed  the  specification  of  a  module  that  had 
already  been  decomposed  and  had  had  its  components  specified.  I  measured  the  amount 
of  change  that  propagated  to  the  component  specifications,  using  once  again  the  metric 
of  number  of  specification  lines  changed. 

(2)  (Horizontal  Change  Propagation).  Second,  I  investigated  the  conditions  under  which  less 
than  full  adherence  to  a  module  specification  affected  that  module's  environment.  The 
horizontal  change  propagation  test  consisted  of  the  following  steps: 

•  I  developed  a  representative  sample  set  of  design  modules,  each  in  the  context  of  a 
larger  design. 

•  I  simulated  the  performance  of  the  modules  in  context. 

•  I  made  "typical”  changes  to  the  modules  and  evaluated  the  k-adherence  of  the 
changed  modules  to  the  specification. 

•  I  re-simulated  the  performance  of  the  changed  modules  in  their  context. 

•  I  determined  under  what  conditions,  if  any,  change  propagated  to  the  studied  modules’ 
environments. 

(3)  (Internal  Robustness).  Third,  I  measured  the  amount  of  modification  that  was  needed  in 
a  large  specification  to  reflect  several  actual  changes  the  design  had  undergone. 


4-t  Experimental  Reeultt. 


4-t.l  Scalability  Teat. 

The  goal  of  this  test  was  to  deduce,  using  data  from  the  experimental  specifications,  an  idea 
of  how  large  the  specification  for  VLSI-scale  designs  would  be. 

Table  4-2  summarizes  the  experimental  data,  and  Figure  4-1  shows  the  relationships 
between  design  sizes  (in  number  of  transistors)  and  specification  sizes  (in  lines).  The  points 
labeled  “F"  represent  the  absolute  size  of  specifications  constructed  at  the  functional  and  four- 
strength  refinement  levels;  The  points  labeled  “D"  represent  the  absolute  size  of  specifications 
constructed  at  the  drive-load  refinement  level;  and  the  points  labeled  "1”  represent  the  size  of  the 
former  specifications  with  their  level-dependent  sections  removed. 

These  data  cannot,  of  course,  be  used  to  guarantee  the  practical  scalability  of  the  proposed 
approach.  They  are  presented  merely  to  show  that,  for  the  specifications  considered,  specification 
size  grew  slowly  with  design  size. 

4-S.S  Malleability  Teat. 

As  was  explained  in  section  4.1.2,  the  evaluation  of  the  proposed  approach's  malleability 
consisted  of  two  phases.  In  the  first  phase,  I  found  that  specification  refinement  permitted  the  fol¬ 
lowing  percentages  of  specification  lines  to  remain  unchanged: 


Refinement 
(Table  3-2) 

Lines  Unchanged1 

%  Unchanged 

functional  to 
four-strength 

77/82 

93.9 

four-strength  to 
drive-load 

69/161 

42.9 

functional  to 
drive-load 

69/161 

42.9 

immaterial  to 
pingrid 

82/112 

73.2 

1  Notation  Entries  nre  of  the  form  n/<  where  a  is  the  somber  of  specification  lines  snchanged  it  the  indicated 
refinement,  and  lit  the  larger  of  (total  nomber  of  lines  is  the  snrefised  specification,  total  nomber  of  lines  in  the  refined 
specification) 
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This  Analysis  confirmed  that  the  partitioning  inherent  in  the  specification  method  allowed  a 
substantia]  fraction  of  old  specifications  to  be  used  in  refined  specifications.  Also,  since  the 
changed  portion  consisted  largely  of  data  type  and  adherence  function  definitions,  which  can  be 
reusable,  the  potential  exists  for  making  refinements  with  little  effort  indeed. 


Further,  although  the  module  studied  in  the  previous  analysis  was  a  small  one,  it  seems  real* 
istic  to  believe  that  this  good  performance  will  hold  in  the  specification  of  larger  modules  as  well, 
in  that  the  percentage  of  specification  lines  that  was  refinement*Ievel*dependent  remained  roughly 
constant  regardless  of  module  size: 


Spec'n 

(Fig) 

Transistors 

(typical) 

%  of  Specification  Level-Dependent 
Functional  4-Strength  Drive/Load 

B-7 

7 

53.2 

3-6 

7 

56.0 

A-l 

7 

77.6 

A-2 

7 

67.9 

A-3 

8 

84  4 

A-4 

35 

68.7 

A-5 

3860 

54.3 

Furthermore,  the  complexity  of  the  transformations  carried  out  in  specification  refinement  appears 
to  be  independent  of  module  size.  Although  larger  modules  require  the  definition  of  more 


different  data  type  operations,  this  increased  volume  is  reflected  in  specifications  at  all  refinement 
levels.  In  summary,  the  specifications  studied  in  this  research  exhibited  good  reusability  and  thus 
were  easy  to  refine. 

Using  the  specification  to  verify  the  design  at  the  functional  and  four*strength  refinement 


levels  was  straightforward.  The  output  from  both  simulation  and  specification  interpretation  was 
in  the  same  digital  format,  and,  because  spike  adherence  functions  could  be  used  meaningfully  at 
these  levels,  comparison  of  the  two  sets  of  outputs  for  equality  satisfied  the  verification  task. 
Verification  decisions  were  rendered  as  either  1-adherence  (if  all  module  pins  adhered  fully),  or 


(otherwise)  O-adbcrence.  At  the  pingrid  syntactic  level,  spike  adherence  functions  are  no  longer 
useful  in  general,  but  this  simply  meant  that  verification  decisions  could  be  rendered  in  terms  of 
k-adherence  for  all  k  in  [0,1], 

At  the  drive-load  semantic  level,  an  inconvenience  arose:  the  output  of  the  simulator  used 
was  in  a  format  (graphic  waveforms)  different  from  the  output  of  the  specification  interpreter 
(numeric  text).  While  ‘.his  problem  was  not  a  conceptual  difficulty  preventing  effective 
verification  of  the  design,  it  does  illustrate  the  desirability  of  integrating  such  a  specification  inter¬ 
preter  into  the  design  tool  suite. 
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4.1.9  Sparenest  Study. 

The  proposed  method  yields  a  specification  with  seven  sections  or  elements.  The  first  three 
sections  are  informational,  providing  an  immediate  abstract  view  of  the  module  to  the  designer. 
The  next  two  sections  are  more  detailed,  and  the  final  two  more  detailed  still.  Through  its  parti¬ 
tioned  structure,  the  proposed  specification  approach  presents  the  module  in  a  layered  way  and 
identifies  which  details  should  be  included  and  which  omitted. 

The  following  observations  may  be  made  about  the  essentiality  and  redundancy  of  the  infor¬ 
mation  contained  in  each  of  the  seven  elements  of  the  proposed  specification: 

(1)  Assumptions.  As  was  tLe  corresponding  section  in  Britton,  Parker,  and  Parnas’s  software 
specification  [Brit81a],  this  section  is  “partially  redundant."  In  addition  to  its  casting  impor¬ 
tant  portions  of  the  formal  sections  to  follow  in  a  more  easily-understood  way,  it  also  expli¬ 
citly  states  premises  that  underlie  the  construction  of  the  remainder  of  the  specification.  It 
would  be  difficult  to  justify  the  essentiality  of  this  section,  but  without  it  the  specification 
would  communicate  much  less  effectively.  The  assumptions  section,  then,  is  included  for 
efficiency  rather  than  for  completeness. 

(2)  Specification  Level.  This  small  section  identifies  the  specification  data  types  being  used.  Like 
the  assumptions  section,  it  too  is  informational. 

(3)  Pin  and  Internal  State  Variable  Summaries.  The  information  in  this  section  essential  to  the 
specification  process  also  could  be  inferred,  in  this  case  from  the  access  function  section. 
Nevertheless,  this  index  facilitates  the  construction  of  a  specification  interpreter  and  also  pro¬ 
vides  an  abstract  view  of  the  module. 

(4)  State  Variable  Attribute  Initializations.  This  section,  which  directly  follows  the  summaries  of 
pin  and  internal  state  variables,  declares  particular  values  for  their  level-specific  attributes. 
Consequently,  this  section  is  clearly  essential,  in  that  it  directly  provides  syntactic  reference 
values  for  static  verification.  Further,  semantic  values  in  this  section  are  referenced  by  access 
functions  for  dynamic  verification.  The  method  provides  identical  facilities  for  including  both 
semantic  information  (usually  functional/electrical)  and  syntactic  information  (which  tends  to 
be  geometric). 


(5)  Accett  Function  Definitions.  The  heart  of  the  specification,  this  section  specifies  the  behavior 
of  each  1C  module  pin.  The  partitioning  of  module  function  into  per-pin  components,  even 
when  these  components  are  identical  or  similar,  need  not  produce  excessive  descriptive  redun¬ 
dancy,  because  common  elements  can  be  factored  out  and  described  by  a  reusable  data  type 
definition.  The  treatment  of  timing  through  a  uniform  implicit  discipline  does  make  the 
description  of  function  slightly  less  compact,  but  large  compensating  dividends  are  gained  by 
the  separation  of  concerns  this  partitioning  produces. 

(6)  Data  Type  Definitions.  The  data  structures,  and  operations  on  them,  comprising  the  generic 
state  type  are  defined  in  this  essential  section.  Separation  of  level-specific  definition  into  this 
section  from  the  access  function  definition  section  is  less  than  optimally  compact;  as  before, 
however,  the  ease  of  refinement  that  such  a  separation  imparts,  with  the  corresponding  gains 
in  malleability,  compensate  for  this  type  of  presentation. 

(7)  Adherence  Function  Definitions.  Without  this  section,  the  specification  could  not  convey  a 
precise  understanding  of  the  relative  merits  of  various  degrees  of  adherence.  Further  research 
is  required  to  determine  whether  this  concept  can  be  conveyed  more  concisely  than  with  such 
functions. 

4.S.4  Change  Management  Tests. 

4.S.4  I  Vertical  Change  Propagation. 

In  this  test,  I  measured  the  amount  of  change  propagated  through  a  single  decomposition 
level  by  several  real-world  changes  applied  to  a  parent  specification.  The  changes  applied  are 
enumerated  in  Table  4-3. 

The  results  of  this  test  are  reported  in  Table  4-4.  Usually,  the  propagated  complexity  was 
of  the  order  of  the  original  change,  a  pleasant  result  considering  that  several  types  of  changes  and 
differing  specification  refinement  levels  were  considered.  For  the  changes  numbered  2  and  4,  how¬ 
ever,  there  was  an  order  of  magnitude  increase  in  the  propagated  change. 


No.  Description _ 

1  Add  a  pin  to  clear  the  accumulator  in  each  of  the 
nine  WASP  processing  elements. 

2  Generate  an  internal  control  signal  to  recirculate 
the  internal  state  of  the  processing  elements. 

3  Correct  an  error  in  the  logic  of  the  processing 
element  function  block. 

4  Change  the  edge  membership  of  module  pads  to  effect  a 
more  balanced  distribution  around  the  chip  perimeter. 

5  Change  from  a  broadcast  to  a  pipelined  clocking 
discipline. 

6  Change  scan-in/scan-out  lines  from  driven  to 
precharged. 

Table  4-3.  Types  of  Changes  Studied 
for  Vertical  Propagation  Effects. 


Change 

No. 

Semantic/ 

Syntactic 

Refinement 

Level 

(Table  3-2) 

Spec'n  Lines 
Changed/ 
Total  Lines 
in  Parent 

Spec’n  Lines 
Changed/Total 
Lines  in 
First-Level 
Children 

Percent 

Propa¬ 

gated 

1 

funct/immat 

5/247 

5/483 

100 

1 

drvload/immat 

7/308 

7/278 

100 

2 

funct/immat 

2/247 

22/503 

1100 

3 

funct/immat 

4/247 

4/503 

100 

3 

drvload/immat 

16/278 

16/775 

100 

4 

funct/pingrid 

98/443 

887/1504 

905 

5 

funct/immat 

19/247 

57/475 

300 

6 

funct/immat 

0/247 

0/503 

0 

Table  4-4.  Vertical  Change  Propagation. 

Notation:  Columns  3  and  4  present  a  ratio,  n/d.  In  column  3,  n  is  the  number  of  lines  changed  in 
the  parent  specification  and  d  is  the  larger  of  (total  number  of  lines  in  unchanged  parent 
specification,  total  number  of  lines  in  changed  parent  specification).  In  column  4,  n  is  the  total 
number  of  lines  changed  in  all  the  specifications  for  the  first-level  child  modules  of  the  parent,  and 
d  is  the  larger  of  (total  number  of  lines  in  all  unchanged  first-level  child  specifications,  total 
number  of  lines  in  all  changed  first-level  child  specifications). 


—  In  the  first  of  these  cases,  change  2,  a  new  internal  module  had  to  be  specified:  it  was  the  fixed 
cost  of  constructing  an  entirely  new  submodule  specification  (even  though  only  20  lines  long) 
that  caused  the  large  percentage  change.  This  result  suggests  that,  while  in-place 
specifications  may  be  easy  to  change,  there  is  a  disproportionately  high  start-up  cost  for  new 
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specifications.  Tools  that  assist  in  creating  routine  portions  of  the  specification  could  alleviate 
this  cost. 

—  The  second  case,  change  4,  exhibited  poor  robustness  chiefly  because  the  proposed  specification 
approach  itself  was  insufficiently  applied.  The  syntactic  data  type  chosen,  pingrid,  called  for 
the  specification  of  absolute  coordinate  points  on  a  two-dimensional  grid.  This  was  not  a  good 
use  of  abstraction.  Consequently,  each  change  to  the  parent  module  specification  rippled 
through  several  first-level  child  modules.  A  better  abstraction,  for  example  one  in  which  edge 
membership  is  described  symbolically,  could  be  expected  to  resist  change  propagation  more 
fully.  A  corollary  observation  might  be  that  less  abstract  data  types  appear  more  susceptible 
to  vertical  change  propagation. 

4.S.4.S  Horizontal  Change  Propagation. 

The  types  of  test  changes  to  be  introduced  into  the  test  module  depended  on  two  factors. 
First,  there  was  the  level  of  refinement  of  the  module  specification.  The  signal  data  types  at  the 
functional  specification  level  are  not  rich  enough  to  admit  value  perturbations  and  still  have  their 
modules  k-adbere  to  specifications  for  any  k>0.  Slight  specification  refinement  (to  include,  say,  a 
small  finite  set  of  signal  strengths),  produced  similarly  unsatisfactory  test-bed  specifications.  I 
chose,  therefore,  to  specify  test  modules  at  a  more  refined  level.  Generally,  the  drive-load 
functional/electrical  level  (Table  3-2)  was  used:  it  was  simple,  but  not  so  much  so  that  essentia] 
specification  elements  were  not  illustrated. 

The  choice  of  adherence  function  also  influenced  the  types  of  changes  that  would  be  found 
interesting  Spike  adherence  functions  (Table  3-3),  which  reduce  k-adherence  to  1-adherence  for 
all  k>0,  and  Square  Band  adherence  functions,  which  are  also  insensitive  to  change  from  a 
k-adherence  standpoint,  were  discarded  for  analysis.  The  Linear  Ramp  and  Normal  functions, 
therefore,  were  chosen  for  the  specifications  used  in  this  study.  For  consistency  of  analysis,  I  used 
the  one-sided  adherence  functions  illustrated  in  Figure  4-2:  the  decreasing  functions  are  recipro¬ 
cals  of  the  increasing  Linear  Ramp  and  Normal  functions,  so  that  a  zero  drive  and  an  infinite  load 
both  have  O-adherence.  Once  the  specification,  including  adherence  functions  o(x),  was  esta¬ 
blished,  changes  were  introduced  by  perturbing  output  values  to  those  values  of  x  for  which 
0  <  a(x)  <  1. 


LRI(x) 


1 


LRD(x) 


Figure  4-2.  Linear  Ramp  (LR)  and  Normal  (N) 
Increasing  and  Decreasing  (I/D)  One-Sided  Adherence  Functions 
Used  in  this  Research. 


Figure  4-3  illustrates  the  canonical  test  environment.  It  consists  of  an  incoming  signal  path, 
a  pin  on  a  module  boundary,  a  propagation  path,  and  an  observation  point.  Note  that  the  obser¬ 
vation  point  can  be  outside  the  test  module,  in  which  case  the  pin  is  an  output  pin  and  the  propa¬ 
gation  path  in  the  module's  environment,  or  it  can  be  inside  the  test  module,  in  which  case  the 
pin  is  an  input  pin  and  the  propagation  path  inside  the  test  module. 

The  testing  showed  that  quantifying  the  amount  of  propagated  change  depends  on  ’  nowing 
both  the  k-adberence  of  the  test  module  and  the  characteristics  of  the  propagation  path.  Alterna¬ 
tively,  the  test  suggested  that  different  adherence  functions  should  be  used  depending  on  the 
intended  utilization  of  module  pin  signals,  so  that  "k-adhcrence"  acquires  a  uniform  meaning  for 


For  small  discrepancies  in  adherence,  a  more  complex  propagation  path  tended  to 
ameliorate  the  effects  of  less-than-full  adherence  to  a  module  specification.  The  simplest  type  of 
path  measured  was  a  bus  (Figure  4-4).  Electrically,  the  pin  and  observation  point  are  the  same 
node  in  this  arrangement,  so  that  the  waveforms  observed  at  the  two  points  are  identical.  Less 
than  full  adherence  to  the  specification  at  the  pin,  therefore,  translates  directly  into  a  similar 
deficiency  in  the  environment.  The  implication  is  that  it  is  important  for  long  (e  g.,  control)  sig¬ 
nal  drivers  to  adhere  fully  to  their  specifications;  consequently,  adherence  functions  for  bus  drivers 
should  be  steeply  sloped. 

Even  a  simple  change  to  the  propagation  path  reduces  the  effect  of  less-than-full  adherence 
Figure  4-5  illustrates  change  propagation  through  a  steered  signal  path  in  uMOS.  Here  the  pin 
and  observed  waveforms,  originally  separated  by  a  threshold  voltage  drop,  tend  to  come  together 
as  k  diminishes. 

This  effect  is  even  more  pronounced  when  signal  restoration  is  included  in  the  propagation 
path.  Figure  4-6  illustrates  that  severe  degradation  of  the  pin  signal  is  possible  before  an  effect  is 
noticed  at  the  observation  point.  However,  as  Figure  4-6  indicates,  a  rapid  crossover  occurs  at 
low  values  of  k:  suddenly  the  observed  signal  becomes  considerably  wors'  than  the  pin  signal. 

This  phenomenon  indicates  that,  for  more  complex  propagation  paths  (especially  those  including 
restoration  of  signals),  careful  design  in  the  propagation  path  may  achieve  moderate  tolerance  to 
less-than-full  specification  adherence.  The  adherence  function  for  such  pins,  then,  should  be 
gently  sloped  around  the  specified  value,  with  a  steep  slope  being  attained  around  the  point  of 
behavioral  failure.  Table  4-5  summarizes  these  results 
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Figure  4-4.  Change  Propagation  through  a  Bus. 


Module  boundary 


observation  point 


k-adhereace 

LRI  NI 


pin  waveform 


observation  point  waveform 


.169 


.0011 

ywv; 

i 

Figure  4-5. 

Change  Propagation  through  a  Steered  Signal  Path  in 
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Figure  4-6. 

Change  Propagation  through  a  Restored  Signal  Path. 


It  is  not  evident  from  these  data  that  continuous  adherence  function  curves  are  needed. 


Piecewise  linear  functions  should  suffice. 


Type  of  Pin 


Adherence  Function  Characteristics 


bus  driver 


should  fall  off  sharply  when 
specified  value  not  achieved 


pass-gate  logic  near-unit  slope  probably  ok 

for  nMOS  implementations 

restored  logic  tolerant  to  small  discrepancies; 

should  fall  off  sharply  around 
failure  point  for  large 
discrepancies 

Table  4-5.  Desirable  Adherence  Functions 
for  Controlling  Horizontal  Change  Propagation. 


4-S-4-S  Internal  Robuetneas. 

Having  illustrated  how  well  the  proposed  approach  resists  change  propagation  from  module 
to  module,  I  now  will  examine  how  much  change  is  introduced  into  a  single  module  specification 
by  typical  real-world  changes.  Each  of  the  changes  enumerated  in  Table  4-3  was  an  actual 
change  made  in  a  real  design.  Observe  from  the  statistics  for  parent  modules  in  Table  4-4  that 
each  of  the  changes,  with  one  exception,  resulted  in  the  modification  of  less  than  10%  of  the  lines 
in  the  specification.  Because  this  specification  approach  emphasizes  partitioning  and  minimal 
redundancy,  it  is  not  surprising  that  the  studied  changes  did  not  result  in  major  specification 
rewriting. 

The  one  change  (change  4)  requiring  over  10%  of  the  specification  lines  to  be  changed  has 
been  identified  before  as  an  instance  of  a  less-tban-optimal  usage  of  the  proposed  approach.  That 
is,  in  this  example  insufficient  use  was  made  of  abstraction.  A  more  abstract  data  type  for  the 
syntactic  specification  information,  such  as  an  extension  of  the  abstractions  used  in  modern  sym¬ 
bolic  layout  systems  (e.g.,  VIVID  |Rose84]),  would  have  improved  specification  robustness  in  this 
example.  With  this  specification  approach,  as  with  all  representation  systems,  it  is  true  th3t 
robustness  under  change  declines  as  the  representation  data  types  become  more  concrete.  Yet 
even  with  the  rather  concrete  data  type  used  in  this  example,  the  partitioning  inherent  in  the 
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proposed  approach  prevented  the  need  for  wholesale  specification  changes:  the  worst-case  change 
of  22%  is  certainly  tolerable. 


CHAPTER  5 


CONCLUSION 

In  this  final  chapter,  I  will  summarize  the  principal  conclusions  from  this  study  and  make 
suggestions  for  future  research. 

5.1  Principal  Conclusions. 

5.1.1  Software  Technology  Transfer  to  VLSI  Design  has  been  Demonstrated. 

Despite  its  intuitive  appeal  (cf.  chapter  1),  the  transfer  of  software  technology  to  VLSI 
design  has  as  yet  been  a  largely  unfulfilled  promise.  Although  similar  approaches  to  common 
problems  can  be  observed  in  software  engineering  and  VLSI  design,  few  of  these  similarities  can 
be  traced  to  an  explicit  attempt  to  transfer  software  technology  [Gros83c].  As  a  result,  some 
skepticism  has  developed  of  late,  and  researchers  are  now  seeking  demonstrations  that  confirm  the 
promise  of  software  technology  transfer. 

The  research  carried  out  in  this  dissertation  is  such  a  demonstration.  Abstract  interface 
specification  techniques  developed  exclusively  in  the  software  domain  were  extended  and  applied 
successfully  to  VLSI  design.  To  recapitulate,  these  techniques  included:  (1)  using  the  definitions 
of  abstract  data  types  in  interface  specifications;  (2)  obtaining  the  precise  partitioning  and  com¬ 
plexity  control  of  module  interface  specifications  using  a  finite  state  machine  and  access  function 
model;  and  (3)  expressing  and  interpreting  these  interface  specifications  with  Hoare’s  Communi¬ 
cating  Sequential  Processes  (CSP)  notation.  That  the  transfer  effort  was  successful  is  evidenced 
by  the  demonstrated  realization  in  VLSI  interface  specifications  (chapter  4)  of  the  benefits  of  these 
software  techniques. 

5.1.2  The  Proposed  Abstract  Interface  Specification  Approach  Has  VLSI-Level  Power. 

To  repeat  from  chapter  1,  VLSI  design  b  integrated  circuit  design  in  which  brute  force  no 
longer  works.  This  research  has  proposed  an  approach  for  abstract  interface  specification  that 
demonstrates  specification  power  appropriate  to  VLSI  complexity  levels. 
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Reasonable  extrapolations  of  parameters  from  specifications  constructed  in  this  study  sug¬ 
gest  strongly  tbat  the  proposed  approach  can  be  used  to  specify  functional^  in  tens  of  pages 
abstract  interfaces  of  designs  whose  implementation  requires  tens  of  thousands  of  devices.  Furth¬ 
ermore,  both  functional  and  performance  specification  are  supported  at  these  levels  of  integration, 
and  high-level  specifications  can  be  evolved  (with  non-trivial  reusability  of  their  contents)  to  pro¬ 
vide  a  verification  frame  at  later  design  stages.  A  third  implication  of  the  data  in  this  study  is 
that  the  total  size  of  performance  specifications,  if  needed,  is  manageable,  roughly  an  order  of 
magnitude  larger  than  the  size  of  the  corresponding  functional  specification.  A  method  of  quanti¬ 
fying  adherence  to  the  specification  is  provided  for  use  at  these  levels  of  detail.  In  summary,  the 
research  provides  a  means  of  realizing  and  exploiting  abstraction  and  precise  partitioning  for 
VLSI-scale  complexity  control. 

5.1.S  VLSI  Design  Specification  it  Difficult  and  Not  UnivcrtaUy  Inepiring. 

This  research  also  confirmed  that  precise  specification,  a  difficult  task  in  the  software 
domain,  is  no  easier  in  VLSI.  Numerous  classes  of  component  assumptions  (section  3.2)  must  be 
included  if  the  interface  specification  is  to  be  complete.  Identification  and  inclusion  of  these 
assumptions  is  a  resource-consuming  process;  abstract  interface  specifications  take  longer  than 
expected  to  construct  and  are  much  larger  than  dear-box  specifications  now  commonly  used  in 
VLSI  design.  As  has  been  noted,  of  course,  such  clear-box  specifications  use  a  monolithic  (unpar¬ 
titioned)  approach  that  strains  or  exceeds  designers’  intellectual  capacities,  even  at  MSI/LSI  lev¬ 


in  this  regard,  I  should  note  that  I  found  in  the  process  of  conducting  this  research  that  the 
value  of  specifications  per  ee  in  VLSI  design  is  not  yet  commonly  embraced1  (a  dificulty  that  also 
exists  in  software).  Accordingly,  much  of  the  research  commonly  suggested  in  the  following  sec¬ 
tion  is  directed  toward  demonstrating  this  value.  Without  a  greater  base  of  agreement  op  the 
merits  of  VLSI  specifications,  research  into  this  topic  will  be  difficult  to  support. 


1  For  example,  u  anonymous  referee  wrote,  is  response  to  an  earlier  partial  draft  on  tbia  reaearch,  "At  a  designer  I 
bate  formal  description  languages  and  tbe  idea  of  executable  specifications.  1  think  both  interfere  with  my  ability  to 
design  effectively  " 
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5.2  Suggestions  for  Future  Research. 

A  substantial  amount  of  follow-on  work  remains  to  be  done  in  abstract  interface 
specification  of  VLSI  designs,  let  alone  in  the  application  of  software  technology  to  VLSI  design 
change  management,  for  which  several  broad  research  projects  were  enumerated  in  chapter  1. 

Here  are  some  of  the  tasks  needed  to  carry  on  the  work  in  abstract  interface  specification. 

5.8.1  Evaluate  Approach ’t  Usefulness  with  Other  Bate  Language t. 

The  abstract  interface  specification  method  described  in  this  dissertation  used  CSP  as  a 
medium  of  expression,  preferring  CSP  to  standard  programming  languages  because  of  its  capabili¬ 
ties  for  segregating  scheduling  concerns  from  functional.  Other  modern  languages  for  concurrent 
programming  have  been  introduced:  would  the  use  of  these  languages,  rather  than  CSP,  make 
representation  of  abstract  interface  specifications  significantly  easier?  In  particular,  the  VHSIC 
Hardware  Description  Language  (VHDL)  [Dewe84,  Shah85j  uses  Ada2  control  structures  both  for 
multitasking  and  for  modular  decomposition.  At  the  same  time,  the  VHDL  is  a  more  hardware- 
oriented  language  than  CSP,  suggesting  that  it  might  be  possible  to  use  the  proposed  technique 
for  specification  and  yet  specify  more  compactly  with  richer  primitives. 

5.2.2  Investigate  Approach ’t  Ueefulnett  for  Top-Down  Detign. 

Circuit  designers,  as  section  2.3  notes,  are  mo6t  comfortable  with  clear-box  specifications,  a 
specification  technique  that  leads  to  bottom-up  design.  It  would  be  revealing  to  discover  how 
easily  designs  could  be  constructed  top-down  in  practice  using  the  proposed  approach:  for  exam¬ 
ple,  by  assigning  a  desirable  capacitance  and  clock  rate  to  a  module  pin  before  the  module’s  inter¬ 
nals  had  been  laid  out  and  simulated  to  learn  these  parameters. 

5.2.S  Specify  Global  Constraints  Better. 

At  present,  there  is  no  efficient  way  of  specifying  constraints  global  to  the  design  module 
(e.g.,  power  consumption,  current  draw,  tessellation,  aspect  ratio)  using  the  proposed  approach.  I 
believe  this  difficulty  to  be  minor  relative  to  the  gains  in  practical  scalability,  complexity  control, 
and  change  management  which  the  proposed  approach  achieves;  nevertheless,  the  perceived  cost- 
effectiveness  of  the  approach  would  be  enhanced  by  a  solution. 

*  Ads  is  a  trademark  of  Ike  U  S  Department  of  Defease 
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5.1.4  Exploit  Adherence  Concepts. 

Quantizing  the  utility  of  specification  adherence,  as  suggested  herein,  is  a  concept  that  could 
be  exploited  further.  To  do  this,  adherence  functions  need  to  be  better  understood  and  to  be 
easier  to  use.  One  possible  way  to  begin  this  would  be  to  develop  by  experience  a  general  set  of 
adherence  functions  and  rules  for  their  interpretation  and  use.  Based  on  the  existence  of  such  a 
set  of  functions,  meaning  could  be  assigned  to  k-adherence  for  particular  values  of  k,  so  that,  for 
example,  “90%-adherence"  would  have  a  commonly-understood  meaning  in  the  design  commun¬ 
ity.  Other  related  research  topics  include  investigating  the  effect  of  composition  on  k-adherence 
and  determining  whether  adherence  functions  are  the  best  way  of  expressing  the  value  of  adher¬ 
ence. 


5.5.5  Study  Use  of  Approach  for  Wider  Range  of  Designs. 

It  would  be  useful  to  learn  the  applicability  of  the  proposed  approach  in  retroactively  speci¬ 
fying  interfaces  of  designs  originally  implemented  in  technologies  other  than  nMOS  and  in  design 
styles  other  than  synchronous,  full-custom.  The  usefulness  of  the  method  for  specifying  interfaces 
of  designs  intended  for  analog  implementation  should  also  be  investigated. 

5.2.6  Refine  Approach  with  Feedback  from  a  Good  Implementation. 

I  fully  agree  with  Brooks  [Broo82]  in  his  statement  that  the  most  productive  software 
engineering  principle  to  be  developed  in  the  last  ten  years  is  the  "incremental  build  ’  app,oacb  of 
Harlan  Mills  [Myer84],  With  this  approach,  rather  than  to  conduct  additional  theoretical 
research.  1  believe  it  would  now  be  far  more  productive  to  refine  the  ideas  expressed  in  this  disser¬ 
tation  using  feedback  from  the  VLSI  design  community.  To  do  this,  one  should  develop  and  field 
a  set  of  good  tools  implementing  the  proposed  approach,  tools  that  include  a  well-engineered 
designer  interface.  Without  such  a  set  of  tools  and  designer  interface,  it  is  fruitless  to  expect  that 
already-overextended  designers  can  be  induced  to  use  the  proposed  approach  sufficiently  to  render 
a  fair  evaluation. 

One  should  not,  however,  underestimate  the  cost  of  such  tool  development,  a  cost  several 
times  the  cost  of  constructing  a  mere  “snapped-together”  implementation  of  the  specification 
principles  proposed  herein  [Broo75].  I  began  this  research  proposing  to  build  and  collect  feedback 
from  such  set  of  tools,  and  it  was  not  until  I  had  invested  numerous  weeks  in  them  that  I 


realized  they  would,  without  ail  order  of  magnitude  more  effort,  be  unacceptably  clumsy  and 
“unmarketable"  (even  gratis)  to  VLSI  designers.  Despite  the  current  interest  in  reducing  such 
costs  through  capital-intensive  methods  (Wegn84j,  the  costs  of  building  prototype  design  tools 
that  are  effective  in  obtaining  essential  feedback  remain  a  major  current  impediment  to  methodo¬ 
logical  research.  This  statement  leads  to  my  final  suggestion. 

5. £.7  Further  Evaluate  Approach’s  Extensibility. 

It  is  common  for  Ph.D.  dissertations  to  include  in  their  final  section  the  phrase,  “The  exten¬ 
sibility  of  the  proposed  approach  to  very  large  designs  at  an  acceptable  cost  has  not  yet  been 
demonstrated."  This  dissertation  is  no  exception;  such  demonstration  of  extensibility,  although  in 
a  final  sense  “the  proof  of  the  pudding,"  is  well  beyond  dissertation  scope.  Meta-research  is 
needed,  now  that  complexity  and  matters  of  scale  are  dominant  concerns  in  so  many  engineering 
research  fields,  to  determine  ways  of  verifying,  at  acceptable  cost,  the  extensibility  of  proposed 
techniques  to  real-world-size  problems. 

Nevertheless,  in  the  absence  of  methods  for  proving  extensibility,  it  would  be  wrong  to  give 
up.  There  is  much  precedent  for  the  subsequent  and  successful  large-scale  application  of  ideas 
that  germinated,  without  certainty  of  extension,  on  a  modest  scale  in  a  laboratory.  It  is  too  early 
to  tell  whether  the  ideas  set  forth  herein  will  enjoy  such  application,  but  I  am  thankful  to  have 
had  the  opportunity  to  develop  them. 
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APPENDIX  A 

SPECIFICATIONS  OF  MODULES  IN  TEST  SET 

Contents1 


Figure 

Module 

B-6,7 

plash  in 

3-6 

plashin 

A-l 

plashin 

A-2 

plashin 

A-3 

fnblk 

A-4 

malu 

A-5 

wasp 

Semantic  Level 

functional 

four-strength 

drive-load 

four-strength 

drive-load 

drive-load 

functional 


Syntactic  Level 

immaterial 

immaterial 

immaterial 

pingrid 

immaterial 

immaterial 

immater'al 


1  See  Table  4-1  for  module  descriptions,  Table  5-2  for  level  descriptions  (Tbe  first  two  specifications  appear  in 
Appendix  6  a  d  in  Chapter  5,  respectively  ) 
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plash  in 

Module  Specification 


ASSUMPTIONS 

Synopsis:  LSSD  memory  element:  static  memory  cell  that  can  convert  to  a  shift  register. 

Site:  delta  x  18  lambda;  delta  y  ~  90  lambda 
Description-01:  Data  is  shifted  from  left  to  right. 

Description-02:  p2sh  =  p2  AND  sh;  p2shbar  =  p2  AND  (NOT  sh);  plshbar  =  pi  OR  (NOT 
sh) 

Notes-01:  Control  signals  can  be  generated  by  cell  rwcntl. 

Related_Documentation:  See  manual  pages  for  rwcntl  and  LSSD  memory. 

Tesselation:  Cells  abut  vertically  to  form  registers  of  arbitrary  length  that  shift  from  left  to 
right. 

Origin-01:  Originally  derived  from  Stanford  Cell  Library  cell  PlaShiftln  (CIF  ID  81). 
Origin-02:  Minor  modifications  by  Hedlund  (UNC)  and  Lospinuso  (UNC). 

SPECIFICATION  LEVEL 

Semantic:  drvload 
Syntactic:  immaterial 

PINS 

Name  AccFn  C/D 

scin  G_ScanIn  C 

scout  P_ScanOut  D 

routbar  P_DataOut  D 

p2sh  S_Shift  D 

p2shbar  S_Hold  D 

plshbar  S_RecircuIate  D 

INTERNAL  STATE  VARIABLES 

left 

right 

state  variable  attribute  initializations 

SCIN.maxIoadcurr  =  275 
SCOUT.mindrivecurr  =  2750 
ROUTBAR.mindrivecurr  =  2750 
P2SH.maxloadcurr  =  300 
P2SHBAR.maxloadcurr  =  300 
PlSHBAR.maxloadcurr  =  350 
left.mindrivecurr  =  2750 
left.maxloadcurr  =  275 
right.mindrivecurr  =  2750 
right. maxloadcurr  =  275 


Figure  A-l.  plathin  Specification. 


ACCESS  FUNCTIONS 


G.Scanln:  none 
P_DataOut: 

#/*****"************************* . •**.*•*••*./ 

#/*  Access  function  P_DataOut: 

#*/ 

!  routbar  ■=  ROUTBAR  — ►  skip; 

P  ScanOut: 

#/** . ****** . ....**.****.***♦.*.*......../ 

#/*  Access  function  P_ScanOut: 

#*/ 

!  scout  =  SCOUT  -»  skip; 


S.Shift: 

^/* ********************** ••*•*»••********** **************/ 

#/*  Access  function  S  Shift: 

#*/ 


?  P2SH  =  p2sh  - 

#  SS  —  signal(P2SH); 

#  ST  =  signal_thresho!d(P2SH); 


[  SS  >=  ST  - 


?  SCIN  =  scin; 


#  steer(SCIN,P2SH,left); 

#  inv(left, ROUTBAR); 

I  SS  <  ST  -»  skip; 


S_Hold: 

# /t****************************************************** J 

#/*  Access  function  S  Hold: 

#*/ 

?  P2SHBAR  =  p2shbar  — 

#  SH  =  signal(P2SHBAR); 

#  ST  =  signa!_threshold(P2SHBAR); 

[  SH  >  =  ST  - 

#  steer  (SCOUT, P2SHBAR, left); 

|  SH  <  ST  -»  skip; 

1 


S_Recirculate: 

# /******************************************************* 

#/*  Access  function  S_RecircuIate: 

#*/ 

T  P1SHBAR  =  pish  bar  — 

#  SR  =  signal(PlSHBAR); 

#  ST  =  signal  threshold(PlSHBAR); 
j  SR  >=  ST  - 

#  steer  (ROUTBAR, P1SHBAR, right); 

#  inv  (right,  SCOUT); 

|  SR  <  ST  -  skip; 

I 
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DATA  TYPE  DEFINITIONS 
/•  Data  Type  Definition: 

•  Drive-Load  semantic  refinement  level. 

•  This  is  a  very  simple  electrical  model  with 

•  symmetric  rise/fall  times. 

•  Immaterial  syntactic  refinement  level. 

• 

*  At  this  level  the  state  variable  data  structure  is 

*  typedef  struct  stvar  { 

*  int  sigvartyp; 

*  int  sigvoltage; 

*  int  sigcurrent; 

*  int  mindrivecurr;/*  Semantic  attribute  •/ 

*  int  maxloadcurr;  /•  Semantic  attribute  •/ 

*  } STVAR  ; 

*  with 

*  sigvartyp  =  variable  type  (==  drive-load/immaterial); 

*  sigvoltage  «=  drive/load  voltage  (millivolts) 

*  sigcurrent  =  average  drive/load  switching  current 

*  (nanoamps) 

*  mindrivecurr  —  specified  minimum  drive  current 

*  (nanoamps) 

*  maxloadcurr  =  specified  maximum  load  current 

*  threshold  (nanoamps) 

*/ 

#define  VHIMAX  5000 
#define  VHIMIN  3800 
#define  VTH  3750 
#define  VLOMAX  1200 
#define  VLOMIN  250 

abs(i) 

int  i; 

{ 

return  ((i  >  0)  ?  i  :  -i); 

} 

in  v(st  input. stout  put) 

STVAR  ‘input,  ‘output; 

{ 

output-»sigvartyp  =  hput-*sigvartyp; 
if  ((input-»sigvoltage  <  =  VTH) 

Stk  (input-»sigcurrent  >=  output-»maxloadcurr))  { 
output— •sigvoltage  VHIMAX; 

output-»sigcurrent  **  output-*mindrivecurr; 

} 

else  if  ((input-»sigvoltage  >=  VHIMIN) 

£ t  (input-*sigrurrent  >**  output— •maxloadcurr))  { 
output-»sigvo!tage  =  VLOMIN; 
output-*sigcurrent  =  -output-»mindrivecurr; 

} 

else  { 

output-*sigvoltage  *  undefined  (VLOMIN,  VHIMAX); 
output-*sigcurrent  “ 
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} 

return; 


undefined  (-output— mindrivecurr, 
output— mindrivecurr); 


signal(input) 

STVAR  ‘input; 

return(abs(input- sigcurrent)); 

} 

signal_threshold(input) 

STVAR  ‘input; 

{ 

return(input-»maxloadcurr); 

} 

steer(input,  control,  output) 

STVAR  ‘input,  ‘control,  *output; 

{ 

output— sigv  arty  p  *=  input— sigvartyp; 
if  ((control— sigvoltage  >=  VHIM1N) 

&£  (control— sigcurrent  >=  control— maxloadcurr))  { 
output— sigvoltage  =*  input— sigvoltage  -  VTH; 
output— sigcurrent  =  input-»sigcurrent; 

} 

else  { 

output— sigvoltage  =  undefined  (VLOMIN,  VHIMAX); 
output— sigcurrent  **» 

undefined  (-control— mindrivecurr, 
control- mindrivecurr); 

return; 


undefined  (lo,  hi) 
int  lo,  hi; 

/*  ’undefined’  represents  a  condition  specified  as 

•  illegal.  It  returns  a  value  for  the  purposes  of 

•  executability  in  the  specification  interpretation. 

•  This  value  should  either  cause  the  interpretation 

•  to  terminate  or  it  should  cause  aberrant  behavior, 

•  in  either  case  alerting  the  designer  to  potential 

•  difficulty. 

•/ 

return  ((hi— Io)*0.5); 
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ADHERENCE  FUNCTION  DEFINITIONS 


Aecett  Fn  / 
P  DataOut 


P  ScanOut 


S_Shift 


Adherence  Function  a[f] 
a(q,x)  — 

«  x-»n#, 

""  “Ti 

where 


tigi,  «>.  -  • . ,  dg, 

are  the  n  variables  in  the  rig  data  type, 
xO  =  P  DataOut(q),  and 
0  <  x  <  xO; 

*=  1,  otherwise. 


a(q.x)  = 

"  x~4">l 
“  i_l  xO-»*tf,  ’ 

where 

rigt,  rifr,  .  .  .  ,  rign 

are  the  n  variables  in  the  rig  data  type, 
xO  =  P_ScanOut(q),  and 
0  <  x  <  xO; 

«ss  1,  otherwise. 


Let 

S_Shift  (q,s)  =  |l»i,  t>2,  .  .  .  ,  vt| 

and 

S_Shifl  (q'  ,8)={i'I(  t4 ,  .  .  . ,  i4  | , 

where  {t>(}  is  the  set  of  values,  of  the  module  state  variables,  that  make  up 
module  state  q.  Then 

I  U  ,  fig 

afa.s.q'  )  =  max  (0,  min  (1,  min  min-j^ - J—  )  ). 

7“1  »  ~***g, 
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S  Hold 


SJIold  (q,h)  —  va,  .  .  . ,  vk  J 

and 

s_Holi  (if  ,h)-{t4,  4 . «4 }, 

where  {t>,}  is  the  set  of  values,  of  the  module  state  variables,  that  make  up  the 
module  state  q.  Thea 

ofq.h.q'  )  «  max  (0,  mis  (1,  mia  mia  tJ  )  )■ 

y«l  i  v) 


S  Recirculate 


S_Rccireulatt  (q,r)  *»  |  V\,  i^,  .  .  . ,  v*  J 

and 

SJRtcireulait  (q'  ,r)  —  1 «4 ,  ,  .  .  .  ,  i4  J , 

where  { u }  is  the  set  of  values,  of  the  module  state  variables,  that  make  up  the 
module  state  q.  Then 

afa.r.q1  )  —  ■“  (0,  mia  (I,  mia  mia  r  *?'  )  ). 

j—  I  i  •, 

Note:  The  adherence  functions  defined  above  are  the  Linear  Ramp  (LR)  functions  introduced  in 
section  3.4.  Because  their  definitions  are  (unfortunately)  complex,  we  shall  abbreviate  them  as 
follows  in  the  remainder  of  this  appendix: 

a[f|  defined  for  will  be  abbreviated  as 

P_DataOut  LR1  [P_DataOutj  (q,x) 

SJShift  LRD  [S_Shift]  (q,s,q’) 
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Module  Specification 


ASSUMPTIONS 

(Same  as  for  previous  specification  (A-l)) 

SPECIFICATION  LEVEL 

Semantic:  Four-strength 
Syntactic:  Pingrid 

PINS 

(Same  as  for  previous  specification  (A-l)) 

INTERNAL  STATE  VARIABLES 

(Same  as  for  previous  specification  (A-l)) 

STATE  VARIABLE  ATTRIBUTE  INITIALIZATIONS 

SCIN.varxpos  =  0  SCIN.varypos  =  2 

SCOUT. varxp  os  =  6  SCOUT. vary  pos  =  2 

ROUTBAR  .varxpos  =  1  ROUTBAR.varypos  =  2 
P2SH. varxp  oe  =  0  P2SH. vary  pos  =  0 

P2SHBAR.varxpo6  =  0  P2SH3AR.  vary  pos  =  1 

PlSHBAR.varxpce  =  0  P1SHBAR.  vary  pos  =  18 

ACCESS  FUNCTIONS 

(Same  as  for  previous  specification  (A-l)) 

DATA  TYPE  DEFINITIONS 
/♦  Data  Type  Definition: 

*  Four-strength  semantic  refinement  level. 

*  Pingrid  syntactic  refinement  level. 

* 

*  At  these  levels  the  state  variable  data  structure  is 

*  typedef  stvar  { 

*  int  sigvartyp; 

*  int  sigfval; 

*  int  sigstrength; 

*  int  varxpos;  /*  Syntactic  Attribute  •/ 

*  int  varypos;  /*  Syntactic  Attribute  */ 

*  } STVAR  ; 

*  with 

*  sigvartyp  =  variable  type  (=  four-strength /pingrid); 

*  sigfval  =  functional  value 

*  in  (0,1,9  (■*  undefined)}; 

*  sigstrength  =  signal  strength  in 

*  (0  (=  unknown), 

*  1  (=  floating), 

*  2  (■*  steered), 

*  3  (=  restored)} 

*  with  signal  strength  codes  semantically  ordered 

*  (i.e.  i  >  j  -*  strength  i  >  strength  j); 

*  varxpos  *=  x  state  variable  grid  position; 


Figure  A-2.  plathin  Specification. 


varypos  —  y  state  variable  grid  position. 


*/ 

(Operator  definitions  same  as  for  Figure  3-6) 
ADHERENCE  FUNCTION  DEFINITIONS 


(Semantic  adherence  functions  identical  to  those  given  for  Figure  3-6.  Additional  functions  fol¬ 
low  for  measuring  syntactic  adherence.  Note  that  the  evaluation  of  these  functions  is  indepen¬ 
dent  of  module  state,  and  that  therefore  this  evaluation  can  take  place  statically.) 

Access  Fn  f  Adherence  Function  alfl _ 


P_DataOut 

a(q,s) 

=  1,  s— ►varxpos  =  ROUTBAR-*  varxpos 

and  s-*varypos  <  ROUTBAR— ‘vary pos  +  1; 
*=>  0  otherwise. 

P_ScanOut 

a(q.«) 

—  1,  s-+varypos  =  SCOUT— ►  vary pos 
and  s-*  varxpos  <  SCOUT-* varxpos  +  1; 

“  0  otherwise. 

S_Shift  a(q,s)  =  1,  s-*varypos  =  P2SH-*varypos 

and  s-*varxpos  >  P2SH-*varxpos  -  1; 

—  0  otherwise. 

S  llold  a(q,s)  =  1,  s— ►varypos  =  P2SHBAR-*  varypos 

and  s—*  varxpos  >  P2SHBAR-»varxpos  -  1; 

=  0  otherwise. 

S_Recirculate  ft(q,s)  =  1,  s— ►varypoe  *  PlSHBAR— varypos 

and  s-»varxpos  >  P1SHBAR-*  varxpos  -  1; 

«=  0  otherwise. 


Figure  A-2.  plaehin  Specification  (Continued). 


Module  Specification 


ASSUMPTIONS 


Synopsis:  ALU  function  block 

Size:  delta  x  *=  42  lambda;  delta  y  =  80  lambda 

Description:  (M.  Lospinuso)  The  function  block  receives  two  inputs,  the  data  register  (BUFOUT) 
and  the  accumulator  (ACOUT).  The  logic  operation  performed  by  the  function  block  is 
specified  by  the  four  function  block  control  lines  (D,  fl,  f2,  and  f3.  The  function  block  opera* 
tions  are  listed  below: 


controls 
fO  1  23 

output 

mnemonic 

controls 
fO  1  23 

output 

mnemonic 

0  0  00 

0 

zero 

1000 

(B+Ay 

BnorA 

000  1 

BA' 

BandA' 

100  1 

A' 

A' 

00  10 

BA 

BandA 

1010 

(BxorA  )* 

BxnorA 

00  11 

B 

B 

10  11 

(B'  A  Y 

BorA' 

0  100 

B'  A 

B'  and A 

1  100 

B' 

B' 

0  10  1 

BxorA 

BxorA 

110  1 

(BAf 

BnandA 

0  110 

A 

A 

1110 

(BA'  Y 

B'  orA 

0  111 

B+A 

BorA 

1111 

1 

one 

Related_Documentation:  WAfer-Scale  Systolic  Processor  (WASP)  Project  Technical  Note,  “dp2 
Data  Path  Module  Specifications,”  July  5,  1984 


Origin -01:  WASP  1.0,  K.  Hedlund  (UNC) 
SPECIFICATION  LEVEL 

Semantic:  Drive-load 
Syntactic:  Immaterial 

PINS 


Name 

acout 

acoutbar 

bufout 

bufoutbar 

fnout 

sbin 

flB] 


AccFn 

S_acout 

S_acoutbar 

S_bufout 

S_bufoutbar 

P_fnout 

P_sbin 

SJ\B\ 


C/D 

D 

D 

D 

D 

D 

D 

D 


B=0..3 


INTERNAL  STATE  VARIABLES 
t[B],  B=0..3 


Figure  A-3.  fnblk  Specification. 
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STATE  VARIABLE  ATTRIBUTE  INITIALIZATIONS 

ACOUT.maxIoadcurr  —  275 
ACOUTBAR.maxloadcurr  “  275 
BUFOUT.maxloadcurr  ™  275 
BUFOUTBAR.maxloadcurr  “  275 
FNOUT.mindrivecurr  *=  5000 
SBIN.tnindrivecurr  “  50000 
F(B].max]oadcurr  —  275,  B«0..3 
t  B  .mindrivecurr  ■*  2750,  B=0..3 
t  B  .maxloadcurr  *=  275,  B=0..3 

ACCESS  FUNCTIONS 


P_fnout: 

. . . / 

#/*  Access  function  P_fnout:  */ 

!  fnout  =  FNOUT  -*  skip; 


P_sbin: 

^ty*******************************************************y 

#/•  Access  function  P_sbin:  */ 

!  fnout  =  FNOUT  -*  skip; 

S_acout: 

^jty******»****  *********  ***********************************/ 

#/•  Access  function  S_acout:  •/ 

?  ACOUT  =  acout  — ► 

#  SA  —  signal(ACOUT); 

#  ST  =  signal_threshold(  ACOUT); 

(  SA  >=  ST  — * 

#  steer(Fl,  ACOUT, t); 

#  steer(t,BUFOUTBAR,tl); 

#  steer(F2,BUFOUT,t); 

#  steerjt,  ACOUT,  t2); 

#  arbitrate4  (t0,tl,t2,t3, FNOUT); 

#  samenode  (FNOUT, SBIN); 

|  SA  <  ST  -*  skip; 


S_acoutbar: 

ft y******************************************************* y 

#/•  Access  function  S_acoutbar:  •/ 

?  ACOUTBAR  =  acoutt  ar  — ► 

#  SA  =  signn!(ACOUTBAR); 

#  ST  =  signal  thresbold(ACOUTBAR); 

[  SA  >=  ST  - 

#  steer(F0,BUFOUTBAR,t); 

#  steer(t, ACOUTBAR, tO); 

#  steer(F3,BUFOUT,t); 

#  steerjt,  ACOUTBAR,t3); 

#  arbitrate4  (t0,tl,t2,t3, FNOUT); 

#  samenode  (FNOUT, SBIN); 

I  SA  <  ST  -»  skip; 
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#/*  Access  function  S  bufout:  •/ 

t  BUFOUT  -  bufout  - 

#  SA  -  signal(BUFOUT); 

#  ST  -  signal  threshoId(BUFOUT); 

(  SA  >*=  ST  - 

#  steer(F2,  BUFOUT,  t); 

#  steer(t,ACOUT,t2); 

#  steer(F3,BUFOUT,t); 

#  steer(t,ACOUTBAR,t3); 

#  arbitrate4  (tO,tl,t2,t3,FNOUT); 

#  samenode  (FNOUT.SBIN); 

|  SA  <  ST  -*  skip; 

1 


S_bufoutbar: 

#/************ . . . •***/ 

#/•  Access  function  S_b«*foutbar:  */ 

?  BUFOUTBAR  =  bufoutbar  - 
#  SA  =  signal(BUFOUTBAR); 


#  ST  «  signal_threshold(BUFOUTBAR); 
|  SA  >=  ST  — 

#  steer(FO, BUFOUTBAR, t); 

#  steer(t,ACOUTBAR,tO); 

#  steer(Fl,ACOUT,t); 

#  steer(t,BUFOUTBAR,tl); 

#  arbitrate4  (t0,tl,t2,t3,FNOUT); 

#  samenode  (FNOUT.SBIN); 

|  SA  <  ST  —  skip; 

1 


S  fO: 

. •• . *,**,„****/ 

#/*  Access  function  S_fO:  •/ 

?  FO  =  fO  -*  skip; 

S  fl: 

#/*  Access  function  S_fl:  */ 

?  Fl  =  fl  -*  skip; 


S_f2: 

^/* ******* ****** ********  ********************* ****** ******  J 

#/*  Access  function  S_f2:  •/ 

?  F2  =  f2  -  skip; 


Figure  A-3.  /nfr/t  Specification  (Continued). 


/ 


#/ 

#/•  Access  function  S  f3:  */ 

?  F3  «  f3  -  skip; 

DATA  TYPE  DEFINITIONS 

(Same  as  for  Figure  A-l,  with  the  following  operations  added:) 

arbitrated  (varl,var2,var3,var4,varout) 

STVAR  *varl,*var2,*var3,*var4,*varout; 

{ 

/•  This  is  a  very  simple  arbitration  strategy.  */ 

varout-»sigvoltage  *» 

max  (varl-»sigvoltage,  var2— ►sigvoltage, 
var3-»sigvoltage,  var4-»sigvoltage); 
varout-*sigcurrent  = 

max  (varl-»sigcurrent,  var2-*sigcurrent, 
var3-»6igcurrent,  var4— ►sigcurrent); 
varout->sigvartyp  =  varl-*sigvartyp; 

} 

samenode  (varl,var2) 

STVAR  *varl,  *var2; 

{ 

var2-»6igvartyp  =  varl— »sigvartyp; 
var2-*sigvoltage  =  varl-*sigvoltage; 
var2-»sigcurrent  =  varl— »sigcurrent; 

} 

ADHERENCE  FUNCTION  DEFINITIONS 


Access  Fn  f  Adherence  Function  al 


S_acout  LRD  S_acout]  (q.s.q'  ) 

S_acoutbar  LRD  S_acoutbar]  (q.s.q'  ) 

S_bufout  LRD  S_bufout]  (q.s.q'  ) 

S_bufoutbar  LRD  S_bufoutbar]  (q.s.q*  ) 
S_fO  LRD  S_fO  (q,s,q'  ) 

S_fl  LRD  S  fl  (q,s,q'  ) 

S_f2  LRD  SJ2  (q,s,q'  ) 

S_f3  LRD  js_f3  (q,s,q(  ) 

P_fnout  LRI  P_fnoutj  (q.s) 

P_sbin  LRI  P_sbin]  (q,s) 


Figure  A-3.  fnblk  Specification  (Continued). 


112 


malu 

Module  Specification 


ASSUMPTIONS 

Synopsis:  WASP  1.3  Minimal  ALU.  Performs  16  Boolean  functions  on  two  bits,  one  from  the 
accumulator  and  one  bit  from  outside  the  data  path.  The  Minimal  ALU  is  the  processing  ele¬ 
ment  of  the  WAfer-Scale  Systolic  Processor  (WASP). 

Size:  delta  x  =  220  lambda;  delta  y  *=  80  lambda 

Description:  Major  component  parts:  input  buffer  (dynamic  storage  during  execute,  pseudo-static 
with  phi£  refresh  during  instruction  load),  accumulator  (pseudo-static  storage),  inverter  pair, 
function  block,  and  superbuffer  (listed  sequentially,  left  to  right). 

The  function  block  receives  two  inputs,  the  data  register  (BUFOUT)  and  the  accumulator 
(ACOUT).  The  logic  operation  performed  by  the  function  block  is  specified  by  the  four  func¬ 
tion  block  control  lines  fO,  fl,  f2,  and  f3. 

The  accumulator  is  a  pseudo-static  storage  cell.  Its  input  can  come  from  the  data  register 
(acextpS),  the  current  accumulator  (aerecpS),  or  the  function  block  (acfnpS).  In  order  to  keep  a 
known  value  in  the  accumulator,  one  of  its  three  input  enable  lines  must  be  enabled  during 
every  phi£  phase  of  an  execute  cycle.  The  accumulator  value  becomes  undefined  if  more  than 
one  accumulator  control  line  is  simultaneously  high  during  any  phiS  phase  of  an  execute  cycle. 
The  accumulator  can  be  cleared  with  the  accumulator  clear  line  (acclrpS).  During  instruction 
load  the  control  line  StHldHAS  goes  high  during  each  phi£  phase,  and  causes  refresh  of  the 
current  accumulator  value. 

The  output  superbuffer  receives  the  function  block  output.  (Synopsis  and  Description  written 
by  M.  Lospinuso.) 

Relaied_Documentation:  WAfer-Scale  Systolic  Processor  (WASP)  Project  Technical  Note,  “dp2 
Data  Path  Module  Specifications,"  July  5,  1984 

Origin-01:  K.  Hedlund,  M.  Lospinuso,  and  E.  Vook  (UNC). 

SPECIFICATION  LEVEL 

Semantic:  Drive-Load 
Syntactic:  Immaterial 


Figure  A-4.  malu  Specification. 
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PINS 

Name  AccFn  C/D 

fO  S_fO  D 

fl  S_fl  D 

f2  S_f2  D 

f3  SJ3  D 

phil  S_phil  D 

pbi2  S_phi2  D 

StHldHA2  S_StHldHA2  D 

acfnp2  S_acfnp2  D 

acbufp2  S_acbufp2  D 

acrecp2  S_acrecp2  D 

ClrAcpx  S_ClrAcpx  D 

DtOut  P_DtOut  D 

Dtln  G  Dtln  C 


INTERNAL  STATE  VARIABLES 

ACINO 

ACINI 

BUFINO 

BUFIN1 

FNOUT 

t[B],  B=0..3 

STATE  VARIABLE  ATTRIBUTE  INITIALIZATIONS 

ACINO.mindrivecurr  =  2750 
ACINO.maxloadcurr  =  275 
ACINI,  mindrivecurr  =  2750 
ACINI. maxloadcurr  =  275 
BUFINO.mindrivecurr  =  2750 
BUFINO.maxloadcurr  =  275 
BLTTNl.mindrivecurr  =  2750 
BUFIN1. maxloadcurr  =  275 
FNOUT. mindrivecurr  =  5000 
FNOUT. maxloadcurr  =  275 
F[B]. maxloadcurr  =  275,  B=0..3 
t(B]  mindrivecurr  =  2750,  B=0..3 
t[B). maxloadcurr  =  275,  B— 0..3 
PHI  1. maxloadcurr  =  200 
PHI2. maxloadcurr  =  200 
STHLDHA2. maxloadcurr  =  275 
ACFNP2.  maxloadcurr  =  275 
ACBUFP2. maxloadcurr  =  275 
ACRECP2.maxloadcurr  =  275 
CLRACPX.maxloadcurr  =  300 
SBIN  .mindrivecurr  “  50000 
DTIN.  maxloadcurr  =  300 
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ACCESS  FUNCTIONS 


G  Dtln:  none. 


P  DtOut: 

#'/••* . . . * . .*.******.....,./ 

#/•  Access  function  P_DtOut:  •/ 

!  DtOut  =  SBIN  -*  skip; 

S_fO: 

#/********••**••*•* . * . *•***•/ 

#/*  Access  function  S_fD:  */ 

?  FO  =  fO  -»  skip; 


S_fl: 

# /******************************************************* j 

#/*  Access  function  S_fl:  */ 

?  Fl  =  fl  -*  skip; 


S  f2: 


#/*  Access  function  S_f2: 
?  F2  =  f2  -♦  skip; 


S_f3: 

^ /*******************************************************/ 

#/*  Access  function  S_f3:  */ 

?  F3  =  f3  —  skip; 

S_StHldHA2: 

^/*******************************************************/ 

#/*  Access  function  S  StHldHA2:  •/ 

?  STHLDHA2  =  StHldHA2  - 

#  SA  =  signal(STHLDHA2); 

#  ST  =  signaI_threshold(STHLDHA2); 

[  SA  >=  ST  - 

#  steer(ACINl,STHLDHA2,ACIN0); 

#  steer(BUFINl,STHLDHA2,BUFIN0); 

|  SA  <  ST  — »  skip; 

] 


S _ phi  1 : 

# /**************************** ********** ***************** j 

#/•  Access  function  S _ phil:  */ 

?  PHI1  =  phil  - 

#  SA  =  signal(PHII); 

#  ST  =  signal_threshold(PHIl); 

[  SA  >=  ST  — 

#  steer(ACIN0,STHLDHA2,  ACINI); 

#  steer(BUFIN0,STHLDHA2,BUFINl); 

#  /*  Evaluate  function  block  */ 

#  inv(AClNl.ACOUTBAR); 

#  inv(BUFINl,BUFOUTBAR); 

#  steer(fO,BUFOUTBAR,t); 

#  steer(t,ACOUTBAR,tO); 
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steer(fl, ACINI, t); 
steer(t,BUFOUTBAR,tl); 
steer(F2,BUFINl,t); 
s  tee  r(t, ACINI, t2); 
steer(F3,BUFINl,t); 
steer(t,AC0UTBAR,t3); 
arbitrate4  (tO,tl,t2,t3,FNOUT); 
samenode  (FNOUT.SBIN); 

SA  <  ST  -♦  skip; 


#/*  Access  functioQ  S_phi2:  */ 

?  PHI2  =  phi2  - 

#  SA  =  signaJ(PHI2); 

#  ST  —  signal_threshold(PHI2); 

[  SA  >=  ST  -* 

?  DTIN  =  Dtln; 

#  steer(DTIN,PHI2,BUFIN0); 

|  SA  <  ST  -♦  skip; 

i 

S_acfnp2: 

/*******************************************************/ 

#/*  Access  function  S_acfnp2:  •/ 

?  ACFNP2  =  acfnp2  - 

#  SA  =  signal(ACFNP2); 

#  ST  =  signaI_threshold(ACFNP2); 
j  SA  >»  ST  — * 

#  steer(FNOUT,ACFNP2,ACINO); 

|  SA  <  ST  -  skip; 

I 

S_acbufp2: 


#/*  Access  function  S_acbufp2:  •/ 

?  ACBUFP2  =  acbufp2  -» 

#  SA  =  signal(ACBUFP2); 

#  ST  =  signal_thresbo!d(ACBUFP2); 

|  SA  >=  ST  - 

#  steer(BUFIN  1  .ACBUFP2,  ACINO); 

SA  <  ST  -*  skip; 


S  acrecp2: 

#/•  Access  function  S_acrecp2: 

?  ACRECP2  =  acrecp2  — 

#  SA  «  signal(ACRECP2); 

#  ST  «=  signal_threshoId(ACRECP2); 
[  SA  >=  ST  - 

#  steer(  ACINI,  ACRECP2.ACIN0); 

I  SA  <  ST  -*  skip; 
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S  CirAcpx: 

#/*  Access  function  S_ClrAcpx: 

?  CLRACPX  -  CirAcpx  - 

#  SA  -  signal(CLRACPX); 

#  ST  —  signal  threshold(CLRACPX); 
|  SA  >«  ST  - 

#  steer(GND,CLRACPX,ACINO); 

I  SA  <  ST  -*  skip; 


DATA  TYPE  DEFINITIONS 

(Same  as  for  Figure  A-3) 

ADHERENCE  FUNCTION  DEFINITIONS 


Access  Fn  f 
S  fO 
S  fl 
S  f2 
S_f3 

S _ phil 

S_phi2 

S_StHldHA2 

S_acfnp2 

S_acbufp2 

S_acrecp2 

S_CIrAcpx 

P_DtOut 


Adherence  Fn 


LRD  S_fO  (q,s,q'  ) 

LRD  S_fl  (q,s,q'  ) 

LRD  S_f2  (q,s,q'  ) 

LRD  S_f3  (q,s,q'  ) 

LRD  S_phil]  (q.s^'  ) 

LRD  S_phi2|  (q,s,q'  ) 

LRD  S_StHldHA2]  (q,s,q'  ) 
LRD  S_acfnp2]  (q,s,q'  ) 
LRD  S_acbufp2]  (q.s.q'  ) 
LRD  S_acrecp2]  (q.s.q*  ) 
LRD  S_ClrAcpx)  (q,s,q'  ) 
LRI  (P.DtOutj  (q,s) 
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ASSUMPTIONS 


wasp 

Module  Specification 


Synopsis:  WASP  1.3,  WAfer-scale  Systolic  Processor. 

Designed  by  Kye  Hedlund,  William  Hargrove,  Margaret  Lospinuso,  and  Eric  Vook,  Univer¬ 
sity  of  North  Carolina  at  Chapel  Hill,  1984. 

For  certain  special-purpose  computations,  systolic  architectures  have  the  potential  for  very 
high  performance.  A  wafer-scale  implementation,  in  which  processing  elements  are  con¬ 
nected  by  a  mesh  of  programmable  switches  on  a  single  wafer,  offers  the  be6t  means  for 
optimizing  6peed  and  reliability  in  systolic  arrays.  The  smaller  size  and  lower  capacitance 
of  on-chip  wiring  permits  higher  speed  than  could  be  obtained  with  discrete  chips  and  exter¬ 
nal  wiring.  On-chip  interconnection  also  brings  greater  reliability  through  a  reduction  in  the 
number  of  components,  and  the  programmable  switch  matrix  lessens  the  impact  of  faults  by 
permitting  the  inclusion  of  redundant  processors  and  local  exclusion  of  bad  processors. 

WASP  1.3,  a  prototype  systolic  wafer-scale  processor,  has  an  array  of  simple  processors 
embedded  in  a  switch  matrix.  The  processors  are  capable  of  performing  all  16  Boolean  func¬ 
tions  on  two  bits.  The  switches  are  programmable  and  can  receive  and  send  data  in  four 
directions.  The  processing  elements  can  also  be  programmed  to  receive  and  send  data  in  four 
different  directions.  Switch  programming  allows  bad  processors  to  be  isolated  from  the  net¬ 
work,  while  level-sensitive  scan  design  (LSSD)  allows  switch  and  processing  element  micro¬ 
code  to  be  shifted  in  at  low  pin  cost. 

Statistics: 

9  processing  elements 

40  programmable  switches 

3860  transistors 

2965  nodes 

3000  x  3000  lambda 

866  cm  metal  wire 

621  cm  polysilicon  wire 

407  cm  diffusion  wire 

Description: 

AH  elements  (switches  and  PE’s)  of  the  7  by  7  array  in  WASP  1.3  have  the  following  SHARED 
PROPERTIES: 

1.  Elements  communicate  only  with  their  4  NEAREST  NEIGHBORS:  (north,  east,  south,  west) 

2.  Communication  between  elements  is  by  a  1-BIT  SERIAL  data  stream. 

3.  Each  element  contains  8  state  bits  which  indicate  its  ROUTING,  i.e.  its  selection  of  input 

and  output  streams  (see  4,  5).  These  bits  are  scanned  in  when  the  machine  is  in  LOAD 
mode  (pin  name  mgl  —  LOAD)  and  the  shift  control  for  the  row  containing  the  element  is 
ACTIVE  (pin  name  shgl<R>  =  1,  R  is  row  no.).  Otherwise  the  current  routing  setting  of 
the  element  is  retained. 

4.  As  INPUT,  each  element  reads  from  a  SUBSET  of  the  four  directions.  The  results  are  not 

defined  when  more  than  one  direction  is  selected  at  a  time. 

5.  As  OUTPUT,  each  element  sends  data  to  a  SUBSET  of  the  four  directions. 
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6.  The  selection  of  inputs  and  outputs  nre  INDEPENDENT.  It  is  not  possible  to  scnn  in  n  new 

setting  for  one  without  nlso  scanning  in  a  new  setting  for  the  other. 

7.  The  element  does  not  behave  differently  if  its  neighbor  in  any  direction  is  a  switch,  pe,  or 

input-output  pad  pair.  (An  input-output  pad  pair  always  listens  to  its  input  and  always 
sends  to  its  output.  These  pads  are  numbered  d<rlcl>_<r2c2>  and  effect  the  sending  of 
a  signal  from  the  element  at  row  rl,  col  cl  to  the  element  at  row  r2,  col  c2,  where  either  rl, 
cl,  r2,  or  c2  is  an  off-grid  index  (0  or  8)). 

Overview  of  WASP  1.3  LOGICAL  LAYOUT  of  elements: 

1.  The  rows  are  numbered  1  to  7  from  top  (north)  to  bottom  (south).  The  columns  are  num¬ 

bered  from  1  to  7  from  left  (west)  to  right  (east). 

2.  Arrangement  of  elements:  there  are  7  rows  of  7  elements  each. 

3.  Pattern  of  elements: 

Odd  rows  contain  only  switches. 

Odd  columns  contain  only  switches. 

PE’s  are  at  the  intersection  of  even  rows  with  even  columns. 

4.  Due  to  a  limitation  in  the  number  of  available  pads,  input-output  pad  pairs  are  found  only  at 

the  ends  of  even  rows  or  columns. 

(Assumptions  section  written  by  Margaret  F.  Lospinuso  and  Eric  R.  Vook) 

SPECIFICATION  LEVEL 


Semantic:  Functional 
Syntactic:  Immaterial 

PINS 


Name 

AccFn 

C/D 

acclr 

S_acclr 

D 

mg] 

S_mgl 

D 

philgl 

S_philgl 

D 

phi2gl 

S_phi2gl 

D 

shgIHLl[R] 

G_shglHLl[R] 

C 

R=1..7 

acscin[C] 

G_acscin[Cj 

C 

C=1..7 

acscoutjC] 

P_acscout[C) 

D 

C=1..7 

d02_12 

G_d02_12 

C 

dl2_02 

P_dl2_02 

D 

d04_14 

G_d04_14 

C 

dl4_04 

P_dI4_04 

D 

d06_16 

G_d06  JO 

C 

dl6_06 

P_dl6_06 

D 

d28  27 

G_d28_27 

C 

d27_28 

P_d27_28 

D 

d48_47 

G_d48_47 

C 

d47_48 

P_d47  48 

D 

d68_67 

G_d68_67 

C 

d67_68 

P_d67_68 

D 

d82_72 

G  d82_72 

C 

d72_82 

P_d72_82 

D 

d84_74 

G_'J84_74 

C 

d74_84 

P_d74_84 

D 

dC6_76 

G_d86_76 

C 

d76_86 

P_d76_86 

D 

d20_21 

G_d20_21 

C 

d21_20 

P_d21_20 

D 
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d40_41  G_d40_41  C 

d41_40  P_d41_40  D 

d60_61  G_d60_61  C 

d61_60  P_d61_60  D 

STATE  VARIABLES 

INDIR[R]!C]  R=“1..7,  C-1..7 

OUTDIR[Rj|C|  R-1..7,  C-1..7 

FUNiR]  C)  R=2,4,6,  C-=2,4,8 

ACBUF  Rj(C]  R=2,4,6,  C=2,4,6 

ACREC  R)(Cj  R=2,4,6,  C*=2,4,6 

ACFN|R]  C]  R=2,4,6,  C=2,4,6 

ACINOJR  |CJ  R=2,4,6,  C«=2,4,6 

ACINl|R  [Cj  R=2,4,6,  C=2,4,6 

BUFINO(R  [C  R=2,4,e,  C=2,4,6 

BUFIN1|R  [C  R=2,4,6,  C=2,4,6 

OUTRAIL  Rj  C]  R=0,2,4,6,8,  C=0,2,4,6,8 

STATE  VARIABLE  ATTRIBUTE  INITIALIZATIONS 
None. 

ACCESS  FUNCTIONS 


#/•  Access  function  P_acscout[lJ:  •/ 

!  acscout(l)  =  ACSCOUT(l]  — *•  skip; 

ft /***•**•••••••••*******•******•*•**•**•*****••*****•***•/ 

ft/*  Access  function  P_acscout[2]:  */ 

!  acscout(2)  =  ACSCOUT|2|  -  skip; 

ft/*  Access  function  P_ncscout[3]:  •/ 

!  acscout(3)  =  ACSCOUT[3j  — *  skip; 

ft  I*  Access  function  P_acscoutj4]:  */ 

!  acscout(4)  =  ACSCOUT[4j  — *  skip; 

ft /*******••***•**•**•#*•••********•••***•***••••****•*•*•/ 

#/*  Access  function  P_acscout[5]:  */ 

!  acscout(5)  =  ACSCOUT[5j  -*  skip; 

ft /************************************************* **•**•/ 

#/•  Access  function  P_acscout(6]:  */ 

!  acscout(6)  =  ACSCOUT|6]  — *  skip; 

ft /*•***•*•*••**•*••••••**••*•*•******••***•****••**•**•••/ 

#/*  Access  function  P_acscout[7j:  */ 

!  acscout(7)  =  ACSCOUT[7]  —  skip; 

ft /****t************************************************** / 

#/•  Access  function  S_acclr:  */ 

?  ACCLR  =  acclr  -*  skip; 

#/*  Access  function  S_mgl:  */ 

?  MGL  =  mg!  -*  skip; 

^l/*******************************************************/ 

#/•  Access  function  S_philgJ:  •/ 

?  PHI1GL  -  pbilgl  - 
|  PHI1GL  —  1  - 
{  MGL  ==  1  - 
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printf  ("Execute  phase,  phil  entered”); 

for  (R*2;  R<8;  R+-2)  {  for  (C«=2;  C<8;  C+«*2)  { 

/*  Compute  Output  Value  */ 

steer(AClNO|RjjCj,PHIlGL,ACINl[Rj|Cj); 
steer(BUFINO[R  [C|,PHIlGL,BUFINl[Rl|C]); 
fnblk(FUNiR][C  ,BUFINl|Rj|Cl,ACINl|R||C), 
OUTRAIL[R  (C]); 

/*  Send  Output,  if  appropriate  •/ 
if  ((0UTDIR|1]|2)&1)  !=  0)  { 

get_inswitch(l,2, in  switch); 

D12J02  *=  OUTRAIL(inswitcL{0]][inswitch[lIJ; 

if1[(OUTDIR|l]|4l&l)  !=  0)  { 
get_inswitch(l,4,inswitch); 

D14_04  =  OUTRAIL[inswitch{OjJ[inswitch[l)); 

if  aOUTDIR|l]{6]&l)  !=  0)  { 
get_inswitch(  1,6, inswitch); 

D16_06  =  OUTRAIL(inswitchjOj]|inswitch[l)); 

if1[(OUTDIR|2][l}&8)  !=*  0)  { 
get_inswitch(2,l, inswitch); 

D21_20  =  OUTRAIL[inswitch{0)][inswitch[l)|; 

ifl[(OUTDIR|4][ll&8)  !=  0)  { 
get_inswitch(4,l, in  switch); 

D41_40  *=  OUTRAIL(in8witch[0]j{in8witch[l]]; 

ifl[(OUTDIR(6][lj&8)  !=  0)  { 
get_inswitch(6,l, inswitch); 

D61_60  =  OUTRAIL(in8witch(0)Jlin8witch|l]]; 

if^((OUTDIR|7i|2l&4)  *=  0)  { 
get_inswitch(7,2,in  switch); 

D72_82  =  OUTRAIL(inswitch[0]j[inswitcb[l]j; 

ifl[(OUTDIR[7][4]&4)  !=  0)  { 
get_inswitch(7,4,inswitch): 

D74_84  =  OUTRAIL[inswitch[0]J[inswitch[l]]; 

if\(OUTDER|7][6]&4)  !=  0)  { 
get_inswitch(7,6, inswitch); 

D76_86  =  OUTRAIL[inswitch[0j)(inswitch[l]]; 

if^((OUTDIR(2]|7j&2)  !=  0)  { 
get_inswitch(2, 7, inswitch); 

D27_28  =  OUTRAILlinswitch[0)l[inswitcb(l)); 

if^((OUTDIR(4][7]&2)  !=  0)  { 
get_inswitch(4,7,inswitch); 

D4f  48  =  OUTRAIL|iuswUch|0]j[inswitch[lJ|; 

} 

if  ((OUTDIR|6]|7]&2)  !=  0)  { 
get_inswitch(6,7,inswitch); 
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# 

# 


D67JJ8  -  OUTRAIL[inswitch[0]][inswitcb|l]]; 

} 

|  MGL  ~  0  - 

#  printf  ("Load  phase,  phil  entered”); 

#  for  (R«l;  R<8;  R++)  { 

?  SHGLHL1[R]  -  shglHLl(R); 

#  } 

#  for  (C«l;  C<8;  C++)  { 

ACSCOUTICJ  -  ACSCIN(C]; 

#  } 

|  ' ((MGL*==*  1)| |(MGL=*=0))  -  skip; 

#  /•  If  MGL  not  defined,  nothing  •/ 

#  /*  is  to  happen.  •/ 

1 

|  PHI1GL  ==  0  -  skip; 


#/*  Access  function  S_phi2gl:  •/ 

T  PH12GL  =  phi2gl  - 
|  PHI2GL  —  1  - 
[  MGL  ==  1  - 

#  printf  ("Execute  phase,  phi2  entered”); 

#  steer(BUFINl[R]|Cj,ACBUF[R][Cj,ACINOjRj[Cj); 

#  steer(OUTRAIL|R][C],ACFN  R)(C],  ACINO|R][C]); 

#  steer ( ACIN 1  [R] [C] , ACREC (R  [Cj,ACINO[R)IC]); 

#  steer(GND,ACCLR,ACINO|R  [C] ); 

#  if  (INDIR|l][2|  ==  1) 

?  OUTRAIL(0|(2]  -  d02_12; 

#  if  (INDIRll][4]  ==  1) 

?  OUTRAILjO)j4)  =  d04_14; 

#  if  (INDIR|l]|6]  —  1) 

?  OUTRAIL|0][6]  =  d06_16; 

#  if  (INDIR(2]|ll  — =  8) 

?  OUTRAIL|2][0)  =  d20  21; 

#  if  (INDIRj4][l|  ==  8) 

?  OUTRAIL(4][0]  =  d40_41; 

#  if  (INDIR(6]|1)  *=*  8) 

?  OUTRAIL[6][0]  =  d60_61; 

#  if  (INDIR|7)|2]  ==  2) 

T  OUTRAIL[8](2]  =  d82_72; 

#  if  (INDml7){4)  — ■  2) 

?  OUTRAIL(8](4]  =  d84_74; 

#  if  (INDIR[7][6]  ==  2) 

?  OUTRAIL[8][G]  =  d86_76; 

#  if  (INDIR|2](7j  -»  4) 

?  OUTRAIL|2]|8]  —  d28_27; 

#  if  (INDIR[4]|7j  »  4) 

?  OUTRAIL(4]j8j  =  d48_47; 

#  if  (INDIR[6]|7] - 4) 

?  OUTRAIL|6](r]  =  d68_67; 

#  for  (R— 2;  R<8;  R+=2)  {  for  (C=2;  C<8;  C+=2)  { 

#  /*  Locate  Input  Source  */ 

#  if  (INDIR[R]|C|  !=  0)  { 

#  get  inswitch(R,C, inswitch); 

#  BUFIN0[R][CJ  - 
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# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 


OUTRAlL[inBwitch[0]]|inswitch{l]]; 

} 

else  BUF1N0|R](C)  -  9; 

}} 

MGL  —  0  - 

printf  ("Load  phase,  phi2  entered"); 


/•  Documented  StHldHA2  signal  is  •/ 
/•  equivalent  to  PHI2GL  k  (MGL)’.  •/ 

steer(  ACINI  JR)  |C]  ,PHI2GL  ,ACIN0[R]  [  C) ); 
steer(BUFINl|Rj|C)4JHI2GL,BUFIN0jRj|C]); 

/»  'BIT’  is  a  counter  which  •/ 
/•  keeps  track  of  whieh  bit  */ 
/•  of  the  15>bit  control  stream  •/ 
/•  is  currently  being  entered.  */ 


if  (BIT*- 15)  BIT-0; 
for  (C— 1;  C<8;  C++)  ( 

?  ACSCINjCj  =  acscin(C); 
for  (R— 1;  R<8;  R++)  ( 
if  (SHGLHLl(R)  —  1)  < 

/•  Bit  stream  is  encoded  into  »/ 


/•  integers  here  as  follows:  */ 

/•  0,1,13,14  -  BIT  14  •/ 

/•  2,3,11,12  -  BIT  12  •/ 

/*  4,5, 6, 7  -  BIT  7  •/ 

/*  Others  as  shown  below:*/ 


if  (BIT—  7)  FUN|R]|C]  =  ACSCINjCj; 
if  (BIT—  8)  ACFNjRjjCj  =  ACSCINjC); 
if  (BIT—  9)  ACRECjRjjCj  -  ACSCINjCj; 
if  (BIT— 10)  ACBUFjRjjCJ  -  ACSCINjCj; 
if  (BIT— 12)  OUTDIRjRjjC)  «  ACSCINjCj; 
if  (BIT— 14)  INDIRjRjjCj  =  ACSCINjCj; 

}  }  ) 

BIT++; 

‘((MGL— 1)||(MGL~0))  -  skip; 


|  PHI2GL  ==  0  -  skip; 


. . . . 

#/*  Access  function  P_dl2_02:  •/ 

!  d  12  02  =  D12  02  -  skip; 

. . . 

#/*  Access  function  P_dl4_04:  */ 

!  dl4  04  =  D14  04  -»  skip; 

#/ . . . . . . 

#/*  Access  function  P_dl6_06:  •/ 

!  dl6  06  —  D16  06  —  skip; 

#/•••• . * . * . . . 

#/•  Access  function  P_d27_28:  */ 

!  d27_28  =  D27_28  -  skip; 

#/ . . . . 

#/*  Access  function  P_d47_48:  •/ 

!  d47_48  =  D47_48  -»  skip; 


/ 

/ 

/ 

/ 

/ 


Figure  A-5.  waf,"  Specification  (Continued) 


#/•  Access  function  P_d67_68:  •/ 

!  d67  68  -  D67_68  -  skip; 

#/*  Access  function  P_d72_82:  •/ 

!  d72_82  —  D72_82  —  skip; 

#/ . . . . . 

#/•  Access  function  P_d74_S4:  */ 

!  d74  84  «=  D74  84  -  skip; 

#/*****•••*•******•*•* . 

#/*  Access  function  P_d76_86:  •/ 

!  d76_86  =  D76  86  -  skip; 

#/„„„*,***,**«*,*„ . . . . . . 

#/*  Access  function  P_d21_20:  */ 

!  d21_20  =  D21  20  -♦  skip; 

I/,,,,.*,,**,,,*,*,,******,*****, . . 

#/*  Access  function  P_d41_40:  */ 

!  d41  40  =  D41  40  -»  skip; 

. . 

#/*  Access  function  P_d61_60:  */ 

!  d61_60  =  D61_60  -  skip; 

I 

DATA  TYPE  DEFINITIONS 


/*  Data  Type  DeGnition: 

*  Functional  semantic  reGnement  level. 

*  Immaterial  syntactic  reGnement  level. 

* 

•  At  this  level  the  state  variable  data  structure  is 

•  typedef  struct  stvar  { 

•  int  sigfval; 

•  } STVAR  ; 

•  with 

•  sigfval  =  functional  value  in  {0,1,9  (=unde8ned)}; 

• 

*  For  efficiency,  operations  are  deGned  on  integers 

*  instead  of  with  reference  to  this  equivalent 

*  structure. 

*/ 

/*  Operator  DeGnitions  are  the  same  as  for  Figure  B-7, 
with  the  following  operations  added:  */ 

/♦  1.  Operations  on  state  variables:  */ 

fnblk  (fun index, stvarl,stvar2,stvarout) 
int  funindex; 
int  stvarl,  stvar2; 
int  *stvarout; 

{ 

if  ((stvarl==9)  ||  (stvar2==9)) 

{ 

•stvarout  =  9; 
return; 

} 


Figure  A-5.  watp  SpeciGcation  (Continued) 
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■witch  (funindex)  { 
case  0: 

•stvarout  —  0; 
return; 
case  1: 

•stvarout  =  stvarl  £  (l-stvar2); 
return; 
case  2: 

•stvarout  «=  stvarl  £  stvar2; 
return; 
case  3: 

•stvarout  =  stvarl; 
return; 
case  4: 

•stvarout  =  (1-stvarl)  £  stvar2; 
return; 

case  o: 

•stvarout  =  stvarl  '  stvar2; 
return; 
case  6: 

•stvarout  =  stvar2; 
return; 
case  7: 

•stvarout  =  stvarl  |  stvar2; 
return; 
case  8: 

•stvarout  =  1-^stvarl  |  stvar2); 
return; 
case  9: 

•stvarout  **  l-stvar2; 
return; 
case  10: 

•stvarout  —  l-(stvarl  *  stvar2); 
return; 
case  11: 

•stvarout  =  l-((l-stvarl)  £  stvar2)); 
return; 
case  12: 

•stvarout  =  l-6tvarl; 
return, 
case  13: 

•stvarout  —  l-{stvarl  £  stvar2); 
return; 
case  14: 

•stvarout  =  l-(stvarl  £  (l-stvar2)); 
return: 
case  15: 

•stvarout  =*  1; 
return; 
default: 

printff’Bad  function  value  Sod", funindex); 

/*  Such  error  flags  are  not  part  of  the  specification. 

•  They  are  included  merely  for  assistance  in  detecting 

•  errors  during  verification.  See  section  3.3.1.3  for 

•  a  discussion  of  differences  between  specifications 


Figure  A-5.  watp  Specification  (Continued). 


*  tod  simulators. 

•/ 

•stvarout  =  0; 
return; 

} 

/•  2.  Local  closed  subroutines,  included  for  efficiency 

*  to  replace  in-line  subroutines. 

•/ 


get_inswitch(currrow, currcol, inswitch) 
int  currrow,  currcol; 
int  inswitch[2]; 

{ 

/"•••••••••••a . . . . 

*  Function  name:  get_inswitch 

*  Parameters:  currrow:  (input)  row  of  active  PE 

*  or  switch 

*  currcol:  (input)  column  of  active  PE 

*  or  switch 

*  inswitch:  (output)  row  and  column  of  PE 

*  or  switch  which  provides  input 

*  to  the  active  PE  or  switch 

*  Assumptions:  7x7  grid  of  switches/PE’s 

*  External  References: 

*  INDIR  (matrix  of  input  switch  settings) 

*  OUTDIR  (matrix  of  output  switch  settings) 

*  Author:  R.  Gross,  March  1985 

****«*•*««•****•••••***•* ...,w. 

extern  int  INDIR[|[8],  OUTDIR[]j8]; 
int  borderl  =  0,  border2  *>*  8; 
int  newrow,  newcol; 


/ 


loop: 

switch  (INDIR[currrow][currcol]) 


case  1: 

newrow=currrow-l; 

newcol=currcol; 

break; 

/*  North 

•/ 

case  2: 

newrow=currrow; 

newcol=currcol+l; 

break; 

/*  East 

*/ 

case  4: 

newrow=currrow+l; 

newcol=currcol; 

break; 

/*  South 

*/ 

case  8: 

newrow=currrow; 

newco'=currcol-l; 

break; 

/*  West 

•/ 

default: 

printf  ("Bad  value  %d  in  INDIR[%d]|%d].", 
INDIR(currrow](currcol], currrow, currcol); 


Figure  A-5.  wasp  Specification  (Continued). 


printf  ("A  value  of  1  has  been  assumed.*); 

newrow=currrow-l; 

newcol=currcol; 

/•  Consistency  Test  */ 

if  ((newrow  !=  borderl)  k&  (newcol  !*=  borderl)  && 

(newrow  !  =  border2)  &&  (newcol  !=  border2)  && 

((invert  (INDIR  currrow][currcol]) 

&  OUTDIR  newrow]|newcolj)  ==  0)) 

{ 

printff  "Inconsistency:"); 

printf  (*lNDIRl%dl|%d]=%d,  OUTDIR[^dl[%dj=%d", 
currrow.currcol.INDIRlcunTOwIlcurrcol), 
newrow, newcol, OUTDIR[newrowjjnewcoI]); 

} 

inswitchjO  =  newrow; 
inswitchjl  =  newcol; 

if  ((newrow  !=  borderl)  &&  (newrow  !=  border2)  && 

(newcol  !=  borderl)  &.&.  (newcol  !=  border2)  &.& 

(((ntwrow  &  1)  !=  0)  ||  ((newcol  &  1)  !=  0))) 

{ 

currrow  =  newrow; 
currcol  =  newcol; 
goto  loop; 

} 

return; 

} 

int 

invert  (dir) 

int  dir; 

/••••••••A*********************************************** 

*  Function  name:  invert 

*  Parameters:  dir:  (input)  1,  2,  4,  or  8,  representing 

*  N,E,S,W  respectively. 

*  Returns:  Input  12  4  8 

*  Output  4  8  12 

*  Assumptions:  Input  is  valid 

*  External  References:  None 

*  Author:  R.  Gross,  March  1985 

*************** **************************** ************  I 

{ 

switch  (dir) 

{ 

case  1:  return  (4); 
case  2:  return  (8); 
case  4:  return  (1); 
case  8:  return  (2); 
default:  return  (0); 

} 

} 


Figure  A-5.  wasp  Specification  (Continued). 


ADHERENCE  FUNCTION  DEFINITIONS 


Access  Fn  f 

Adherence  Function  a(f] 

P_acscout|C) 

C=1..7 

a(q,») 

«  1  if  s  — =  P__aeseout|C]; 
-*  0  otherwise. 

S_acclr 

a(q,*.q'  ) 

=  1  if  q’  “  S_acclr(q,s); 
=  0  otherwise. 

S_mgl 

a(q.»,q'  ) 

-«  1  if  q’  «*  S_mgl(q,s); 

*=  0  otherwise. 

S_pbilgl 

a(q,s,q'  ) 

=  1  if  q’  =  S_pbilgl(q,s); 
0  otherwise. 

S_phi2gl 

a(q.».q'  ) 

=  1  if  q’  ==  S_phi2gl(q,s); 
=  0  otherwise. 

Figure  A-5.  wasp  Specification  (Continued) 
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ILLUSTRATION  OF  SPECIFICATION  EXECUTION 


doutpt 

(1) 

doutpt 

(2) 

doutpt 

(8) 

o 

u 

t 

p 

t 

plashin 

(1) 

plashin 

(2) 

1 

plashin 

(8) 

control 


To  execute  this  interconnection  of  eight  ‘plashin'  shift  register  cells,  I  used  19  simple  module 
processes.  In  addition  to  the  ‘plashin’  module  process,  which  was  obtained  by  copying  the 
specification  (see  Figure  3-6): 

—  'doutpt(i)'  reported  module-specific  output  from  each  register  cell; 

—  ‘inpt’  and  '<  utpt’  provided  and  reported  register  test  input  and  output,  respec'ively;  and 

—  ‘control'  was  an  environment  process  which  provided  control  stimuli. 

Each  module  process  was  specified  independently  of  the  others;  only  a  simple  “channel  file"  (con¬ 
taining  only  eyntaclie  information)  was  used  to  describe  interconnections.  The  CSP/81  language, 
described  in  section  3.3  of  the  text,  was  the  medium  used  for  representing  both  module  process 
specifications  and  the  channel  file. 

This  specification  execution  was  performed  at  a  functional  refinement  level;  with  minor 
modifications,  interpretations  at  a  more  refined  level  (not  presented  here)  were  also  obtained. 

Also,  with  suitable  type  conversion  mechanisms  included  in  specification  data  type  definitions, 
mixed-refinement-level  execution  was  obtained  (e.g.,  ’doutpt’  was  specified  at  a  lesser  refinement 
level  than  ‘plashin  ).  The  same  channel  file  sufficed  throughout. 


####################################################### 

#  Name:  nplashin 

# 

#  Function:  This  is  a  n-plashin-cell  interconnection. 

#  One  must  set  n  in  the  first  statement. 

# 

#  Author:  R.  Gross,  October  1084 

####################################################### 

set  n  8 

array  plashin  l:n 
array  doutpt  l:n 

#  datapath: 

connect  inpt.ScOut  to  plashin(l).ScIn 

for  i  2  :  n 

connect  plashin(i-l).ScOut  to  plashin(i).ScIn 

connect  pIashin(i*l).DOut  to  doutpt(i-l).DIn 

end  for 

connect  plashin(n). ScOut  to  outpt.ScIn 

connect  plashin(n).DOut  to  doutpt (n).DIn 

#  control: 

for  i  1  :  n 

connect  control.s(i-l)  to  plashin(i).s 

connect  control.r(i-l)  to  plashin(i).r 

connect  control.h(i>l)  to  plashin(i).h 

connect  control.od(i-l)  to  doutpt(i).od 

end  for 

connect  control.os  to  outpt.os 


Figure  TM.  Channel  File. 


##include  <stdio.b> 
process  control :: 

output  port  iot  s(8) ; 
output  port  iot  h(8) ; 
output  port  iat  r(8) ; 
output  port  int  od(8); 
output  port  int  os; 
mt CELLS ; 
int  count  ; 
char  command; 
char  linejlOOj; 
int  i; 

command  —  '  '  ; 

CELLS  «=  8  ; 

*[  command  !=  ’q’  — * 

#  printf  ("Enter  s  for  shift,  h  for  hold,  q  for  quit:”); 

#  fgets(line,100,stdin); 

#  command  =  lineJO]; 


#  /•  Shift:  •/ 

#  /•  stimulate  shift  (s)  •/ 

#  /•  and  recirculate  (r)  repeatedly.  */ 

#  /•  o  is  used  to  trigger  the  printed  output.  •/ 


(  command  ==  's’  — ► 


# 

for  (i  =  0;  i  <  CELLS;  i++)  { 

•  »(')  “  L 

# 

} 

# 

for  (i  =  0;  i  <  CELLS;  i++)  { 

!  »(•)  =  0; 

# 

} 

# 

for  (i  =  0;  i  <  CELLS;  i-i  +)  { 

!  od(i)  =  1; 

# 

} 

!  os  =  1; 

# 

for  (i  ==  0;  i  <  CELLS;  i++)  { 

■  r(i)  =  1; 

# 

} 

# 

for  (i  =  0;  i  <  CELLS;  i++)  { 

l  r(i)  =  0; 

# 

} 

# 

for  (i  =  0;  i  <  CELLS;  i++)  { 

!  od(i)  «=  1; 

#  } 
!  os  =  1; 


Figure  B-2.  control  Module  Process. 


=*:=*  %%  %  %  =*=*:  =*=* 


#  /*  stimulate  hold  (h) 

#  /•  and  recirculate  (r)  repeatedly. 

#  /•  o  is  used  to  trigger  the  printed  output. 


•/ 

•/ 

•/ 


|  command  «*=—  ’h’  —» 

#  for  (i  —  0;  i  <  CELLS;  i++)  { 
!  *»(>)  - 1; 

} 

for  (i  «=  0;  i  <  CELLS;  i++)  { 
!  h(0  -  0; 

} 

for  (i  =  0;  i  <  CELLS;  i++)  { 
!  od(i)  =  1; 

} 

!  os  =  1; 

for  (i  =  0;  i  <  CELLS;  i++)  { 
•  r(i)  -  1; 

} 

for  (i  *=*  0;  i  <  CELLS;  i++)  { 

t  r(i)  =  0; 

} 

for  (i  =  0;  i  <  CELLS;  i++)  { 
!  od(i)  =  1; 

#  } 

!  os  =  1; 


end  process 


Figure  B-2.  control  Module  Process  (Continued). 


##include  <stdio.h> 
process  doutpt  :: 
guarded  input  port  int  od; 

input  port  int  Din  ; 

int  val  ; 
int  O  ; 

#/•  read  and  print  output  values  */ 

*[  ?  O  -  od  - 

I  O  —  1  - 

?  val  =  Din; 

#  printf(”Data  Output  Cell  %&  value  *=  %d”, 

#  csp_proc_num,  val); 

#  Blush  (stdout) ; 

|  O  ==  0  —►  skip  ; 

I 

I 

end  process 


Figure  B>3.  doutpt  Module  Pr- 


##include  <stdK>.h> 
process  inpt :: 

output  port  int  ScOut  ; 


!  ScOut  ■■  0; 
!  ScOut  «■  0; 
I  ScOut  1; 
I  ScOut  •»  1; 
!  ScOut  ■**  0; 
!  ScOut  ■=  0; 
!  ScOut  =  1; 
!  ScOut  =  1; 


!  ScOut 


end  process 


Figure  B-4.  inpt  Module  Process. 


■.v.\ AM.vK'VlV  **  ■ 


##include  <stdio.h> 
process  outpt  :: 
guarded  input  port  int  os; 

input  port  int  Scln  ; 

int  val; 
int  O; 

#/*  read  and  print  output  values  */ 

•|  ?  O  *=  os  - 

[  o  =====  1  - 

?  val  =  Scln; 

#  printf^Scan  Output  value  =  %dn,  val); 

#  Blush  (stdout) ; 

|  o  ==  0  -»  skip  ; 

1 

1 

end  process 


Figure  B-5.  outpt  Module  Process 
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##include  <stdio.h> 
process  plashia  :: 

input  port  int  Scln  ; 
guarded  input  port  int  s  ; 
guarded  input  port  int  h  ; 
guarded  input  port  int  r  ; 
guarded  output  port  int  ScOut ; 
guarded  output  port  int  DOut ; 


int  left  ; 
int  right  ; 
int  DOIT; 
int  SCIN; 
int  SCOUT; 
int  S  ; 
int  H  ; 
int  R  ; 


#/•  Initialize. 

#/*  9  means  undefined. 

left  =  9; 
right  —  9; 


•/ 

•/ 


#/*  Poll  input  ports: 


►I 


^/*********************************************»*********/ 
#/*  Access  function  P_DOut: 

#*/ 

!  DOut  *=  DOUT  -*  skip; 


!  ScOut  —  SCOUT  -*  skip; 


^  ^**»* ****************************************** ********* j 

#/*  Access  function  S_s: 

#*/ 

|  ?  S  =  »  — 

#  SS  =  signai(S); 

#  ST  =  signal_threshoId(S); 

|  SS  >==  ST  -» 

T  SCIN  =  Scln; 

#  steer(SCIN,S,left); 

#  inv(Ieft,DOUT); 

|  SS  <  ST  -*■  skip; 


Figure  B-6.  plathin  Module  Process. 


#/*  Access  function  S_h: 


#•/ 

|?H-h- 

#  SH  -  signnl(H); 

#  ST  •»  signal_threshold(H); 
|  SH  >-  ST  - 


#  steer  (SCOUT  ,H, left); 

|  SH  <  ST  -  skip; 

1 

#/*  Access  function  S_r: 


#*/ 

|  ?  R  =  r  — 

#  SR  —  signal(R); 

#  ST  —  signal_threshold(R); 

|  SR  >=  ST  — 

#  steer  (DOUT,R, right); 

#  inv  (right,  SCOUT); 

|  SR  <  ST  — »  skip; 

I 

] 

end  process 


Figure  B-6.  plaehin  Module  Process  (Continued). 
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/•  Data  Type  Definition: 

•  Functional  semantic  refinement  level. 

•  Immaterial  syntactic  refinement  level. 

• 

•  At  this  level  the  state  variable  data  structure  is 

•  typed ef  stvar  { 

•  int  sigvartyp; 

•  int  sigfval; 

•  } STVAR  ; 

•  with 

•  sigvartyp  =  variable  type  (=  1) 

•  sigfval  —  functional  value  in  {0,1,9  (=  undefined)} 

•/ 

#define  INFINITY  65535 

inv(varl,var2) 

STVAR  *varl,  *vaT2; 

{ 

var2-*sigvartyp  *  varl-*sigvartyp; 
var2-»sigfval  =  (varl-*sigfval  *==  9) 

?  9  :  (1  -  varl-*sigfval); 

return; 

} 

int 

signal(varl) 

VAR  *varl; 

{ 

return(INFINITY); 

} 

int 

signal_threshoId(varI ) 

VAR  *varl; 

{ 

return(O); 

} 

steer(varl,var2,var3) 

STVAR  *varl,  *var2,  *var3; 

{ 

var3— ►sigvartyp  =  (vax2-*sigfval  *==  1) 

?  varl-»sigvartyp  :  var3-*sigvartyp  ; 
var3-*sigfval  ■=  (var2-*sigfval  ==»  1) 

?  varl-*sigfval  :  var3-»sigfval  ; 

return; 

} 


Figure  B-7.  Data  Type  Definitions. 


(User  input  preceded  by  Ul:') 


UI:  cap  -o  ptyp.def.o  nplashin  control 
UI:  (same  line,  cont’d)  doutpt  inpt  outpt  plashin 
channel  file  is  nplashin 
control: 
doutpt: 
inpt: 
outpt: 
plashin: 

Linking. 

Running. 

Enter  s  for  shift,  h  for  hold,  q  for  quit: 

UI:  s 

Data  Output  Cell  1  value  =  1 
Data  Output  Cell  2  value  =  9 
Data  Output  Cell  3  value  =  9 
Data  Output  Cell  4  value  =  9 
Data  Output  Cell  5  value  =  9 
Data  Output  Cell  6  value  =  9 
Data  Output  Cel!  7  value  =  9 
Data  Output  Cell  8  value  =  9 
Scan  Output  value  =  9 
Data  Output  Cel!  1  value  =  1 
Data  Output  Cell  2  value  =  9 
Data  Output  Cell  3  value  —  9 
Data  Output  Cell  4  value  «=  9 
Data  Output  Cell  5  value  =  9 
Data  Output  Cell  ft  value  =  9 
Data  Output  Cell  7  value  =  9 
Data  Output  Cell  8  value  =*  9 
Enter  s  for  shift,  h  for  hold,  q  for  quit: 

Scan  Output  value  =  9 


Figure  B-8.  Sample  Output. 


Data  Output  Cell  1  value  *=  1 
Data  Output  Cell  2  value  “  1 
Data  Output  Cell  3  value  —  0 
Data  Output  Cell  4  value  0 
Data  Output  Cell  S  value  0 
Data  Output  Cell  6  value  ■*  0 
Data  Output  Cell  7  value  —  0 
Data  Output  Cell  8  value  ■■  9 
Scan  Output  value  **  9 
Data  Output  Cell  1  value  *=  1 
Data  Output  Cell  2  value  =  1 
Data  Output  Cell  3  value  =  9 
Data  Output  Cell  4  value  =  g 
Data  Output  Cell  5  value  =»  9 
Data  Output  Cell  6  value  =  9 
Data  Output  Cell  7  value  —  9 
Data  Output  Cell  8  value  *=  g 
Enter  s  for  shift,  h  for  hold,  q  for  quit: 
Scan  Output  value  =  9 
h 

Data  Output  Cell  1  value  =*  1 
Data  Output  Cell  2  value  =  1 
Data  Output  Cell  3  value  =  9 
Data  Output  Cell  4  value  =  9 
Data  Output  Cell  5  value  =  9 
Data  Output  Cell  6  value  =  9 
Data  Output  Cell  7  value  *=  9 
Data  Output  Cell  8  value  **  9 
Scan  Output  value  ==  g 
Data  Output  Cell  1  value  =  1 
Data  Output  Cell  2  value  =  1 
Data  Output  Cell  3  value  =  9 
Data  Output  Cell  4  value  =  9 
Data  Output  Cell  5  value  =  9 
Data  Output  Cell  6  value  =  9 
Data  Output  Cell  7  value  =  9 
Data  Output  Cell  8  value  =  9 
Enter  s  for  shift,  h  for  hold,  q  for  quit: 
Scan  Output  value  =  9 
9 

alt  fail  dine  74,control.c(0).  error  1 
write  dine  7,inpt.c(0).  error  3 


Figure  B-S.  Sample  Output 
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